Anonymization

To permanently remove personal user data from OpenLM usage records and meet privacy and data-protection obligations, such as the General Data Protection Regulation (GDPR), use Anonymization. It is built for administrators who are responsible for data governance. You decide which user details are personal, who they belong to, and when they are anonymized, and Anonymization applies those decisions consistently across the data OpenLM Platform has collected.

What Anonymization does

OpenLM Platform collects usage data, such as license checkouts, process sessions, denials, and dongle activity, and each record identifies the user it belongs to by details such as username, full name, email address, and phone number. Retaining that personal data indefinitely is often neither necessary nor permitted. Anonymization replaces those details with irreversible hashed values so that the usage statistics remain intact while the person behind them can no longer be identified.

With Anonymization, you can do the following:

• Anonymize personal data continuously, on a schedule, or on demand, without deleting the underlying usage history.
• Choose exactly which user fields to anonymize, from the username and email address to the department, phone number, and office.
• Anonymize only the users that match a policy, by country, department, source, and directory group.
• Exempt specific users from a policy so that their data is preserved.
• Fully erase an individual or a group on request, removing them from Users and Groups and anonymizing all of their data. This is the operation behind a "right to be forgotten" request.
• Track every anonymization run in real time and review a searchable history of what was anonymized and when.

How Anonymization works

Anonymization is organized around two entities, which also correspond to the two items in its navigation:

• Policies: rule-based anonymization that runs automatically when its conditions are met. A policy defines which fields to anonymize, which users it applies to, and what triggers it. You can turn a policy off to pause it without deleting it.
• Single anonymization: a one-time run that you start yourself. Its status and results appear in History, alongside your scheduled policy runs.

What "anonymize" means

When Anonymization processes a field, it replaces the value with a SHA-256 (Secure Hash Algorithm) hash, a fixed-length string of letters and numbers that cannot be reversed back to the original value. This is a one-way transformation, not encryption: no key restores the original data.

Most fields are hashed deterministically, so the same input always produces the same output. This keeps usage reports consistent. For example, two anonymized sessions that belonged to the same person still group together. Two fields, Username and UnifiedUsername, are hashed with a random salt (a random value added before hashing) instead, so each run produces a different value. This prevents conflicts in Users and Groups, where usernames must stay unique, when a name is reused after an earlier user was anonymized. You can tell the two kinds apart in anonymized data by their length: a salted username becomes an 80-character value (the salt followed by the hash), while every other field becomes a 64-character value.

Fields with no value, including values that are only spaces, stay empty rather than hashed. A user whose selected fields are all empty is skipped entirely and is not counted in the run's results.

What data is affected

A policy or a broad single anonymization anonymizes the selected personal fields in the usage data that OpenLM Platform has collected. It does not rename or remove the user's entry in Users and Groups. The user record keeps its original details, and future usage is recorded under them again.

An absolute single anonymization goes further: it anonymizes all fields and removes the selected users from Users and Groups. OpenLM Platform permanently deletes their anonymized data in Users and Groups about a week later. Use it when the person must disappear from OpenLM Platform entirely, such as for a "right to be forgotten" request.

What triggers a policy

A policy's type controls when it runs. All three types anonymize the fields you select for the users who match the policy criteria. They differ only in timing. The following table lists the types:

Type (as shown)	When it runs	Typical use
On sessions closed	Each time a session closes, if the session's user matches the policy.	Anonymize personal data continuously as usage is recorded, so stored data is never identifiable for longer than a session.
On a relative date	Every day at a set time, on all data older than a threshold you define (for example, older than 6 months).	Enforce a rolling retention window: keep recent data identifiable and anonymize anything past the limit.
On a fixed date	Every day at a set time, on data that falls within a fixed start and end date. The range must lie in the past.	Anonymize a specific historical period, such as a past project or an employee's tenure.

Note

OpenLM Platform interprets the trigger time in the time zone configured in UI Configurations and converts it to UTC when you save the policy. The schedule then runs on a UTC clock. If your time zone observes daylight saving, the run shifts by an hour against your wall clock after a daylight-saving change.

Sessions come from across OpenLM Platform. The On sessions closed type responds to closed sessions from Dongle Monitoring, process sessions, touchpoint events, monitored sessions, denials, disposable tokens, and monitored allocations.

How policy criteria combine

A policy can filter users by country, department, source, and directory group. These criteria combine: a user is anonymized only if they match every criterion you set. A criterion you leave empty is ignored.

For example, a policy with countries United Kingdom and Spain and source Directory Sync anonymizes a user whose country is United Kingdom and whose source is Directory Sync, but not a user whose country is United Kingdom and whose source is System.

Two details apply to the criteria:

• The Group criterion matches the group's direct members only. Users who belong only to a nested subgroup of the selected group are not matched, so select the subgroups too if you need them covered.
• The Countries and Departments criteria never match users whose country or department field is blank. To reach such users, leave those criteria empty.

Warning

A policy with no criteria at all matches every user in the system. Anonymization warns you before it saves such a policy. See Safeguards and restrictions.

Before you begin

Confirm these prerequisites:

• Access to OpenLM Platform, with the Anonymization service available to your organization.
• An Anonymization administrator role to create policies or run anonymizations, or the viewer role to review them. See Roles and permissions.
• User data in Users and Groups, which supplies the users, groups, and fields that Anonymization works with.
• OpenLM usage data collected (for example, through Install Broker and Install Workstation Agent), so that sessions are available to anonymize.

Roles and permissions

What you can do in Anonymization depends on your assigned role. The following table lists the roles:

Role	What you can do
Anonymization administrator (Anonymization_Admin)	Full access. View policies and history, create and edit policies, turn them on and off, delete them, run single anonymizations, and manage exemptions. Account administrators have the same access.
Anonymization viewer (Anonymization_Viewer)	Read-only access. View the policy list and the History page. Cannot create, edit, duplicate, turn on, turn off, or delete policies, and cannot run a single anonymization.

Viewers still see the administrator controls: Add Policy, Single Anonymization, the buttons that turn policies on or off and delete them, and the per-row edit and duplicate icons. The actions are blocked, so selecting them does nothing.

A signed-in user who has neither role sees a "not enough permissions" message instead of the interface. The navigation is hidden until a role is granted, but the header and Log Out stay available. If this happens to you, contact your OpenLM administrator to request access.

Key terms

The following table lists terms that appear throughout this guide and the interface:

Term	Meaning
Anonymize	Replace a value with an irreversible SHA-256 hash so the original cannot be recovered.
Policy	A saved rule that anonymizes selected fields for matching users when its trigger condition is met.
Single anonymization	A one-time anonymization run that you start manually, either broad or absolute.
Broad anonymization	Anonymizes the fields you select for users who match criteria you define.
Absolute anonymization	Anonymizes all fields for the specific users or groups you select and removes them from Users and Groups.
Criteria	The country, department, source, and group filters that decide which users a policy or broad run applies to.
Exemption	A user you exclude from a policy so that their data is never anonymized by it.
Threshold	For a relative-date policy, the age past which data is anonymized (a number plus a unit of days, weeks, months, or years).
Trigger time	The time of day a scheduled policy runs.
Anonymized field	A user field selected for anonymization, such as Email, Country, or Phone.

Get started

This section covers how to open Anonymization, what the interface contains, and the typical workflow.

Open Anonymization

To open Anonymization, select it in the OpenLM Platform Navigation menu, or go to an address of this form in your web browser:

https://cloud-XX.openlm.com/anonymization/#/anonymization

In this address, cloud-XX is your OpenLM Platform instance (for example, cloud-us).

Anonymization uses OpenLM Platform single sign-on, so it has no separate sign-in form. If you are not already signed in, your browser redirects you to the OpenLM sign-in page and returns you to Anonymization afterward. To sign out, open the account menu in the header and select Log Out.

Explore the interface

To manage policies, open Anonymization. To review runs, open History. The header shows the product name, Anonymization, and your signed-in account. The navigation has two items, grouped under section labels:

Item	Group	Purpose
Anonymization	Management	The home page. Lists your policies, and provides the actions to create policies and to start a single anonymization.
History	Operational	A record of every anonymization run, scheduled and one-time, with live progress and results.

The Anonymization workflow

A typical workflow has these steps:

1. Decide which user fields count as personal data for your obligations.
2. On the Anonymization page, add a policy that anonymizes those fields for the intended users and trigger.
3. (Optional) Add exemptions for users whose data you must retain.
4. For one-off requests, run a broad or absolute single anonymization when you need to act once rather than on a schedule.
5. On the History page, confirm that runs complete and review which users were anonymized.

Work with anonymization policies

To create, edit, or manage policies, open the Anonymization page. It lists every policy you have defined.

View policies

The following screenshot shows the policy list:

The Anonymization page lists your policies with their type, field count, and last run.

The following table lists the columns of the policy list:

Column	Description
Policy Name	The name of the policy. A disabled policy is marked with an icon (its tooltip reads "Policy is disabled") and a grayed-out name.
Policy Type	The trigger type, shown by its internal name: ClosedSessions (On sessions closed), RelativeDateRange (On a relative date), or FixedDateRange (On a fixed date).
Anonymized Fields	How many fields the policy anonymizes. The value reads 0 when none are set, a count such as 3, or All users' data when every field is selected.
Last Run	When the policy most recently ran.

Use the toolbar to refresh the list, filter by Policy Name or Policy Type, add a policy, or start a single anonymization. Select one or more policies with the row check boxes to turn them on or off, or to delete them. Pointing at a row also reveals its Edit and Duplicate icons.

Create a policy

Only administrators can create policies.

1. On the Anonymization page, select Add Policy.

   The following screenshot shows the Add Anonymization Policy form:

   The Add Anonymization Policy form. The Summary at the bottom restates the policy in plain language as you fill it in.

2. Under 1. Select policy type and parameters, do the following:

   1. In Policy name, enter a unique name. The name is required, and it cannot be changed later.
   2. (Optional) To save the policy paused, set the toggle to Disabled. Otherwise, leave it set to Enabled so the policy is active.
   3. Select a policy type: On sessions closed, On a relative date, or On a fixed date. See What triggers a policy.

3. Set the policy criteria, which are the users the policy applies to. All criteria are optional, and a user must match every one you set:

   • Countries: one or more user countries.
   • Departments: one or more departments.
   • Group: one or more directory groups.
   • Source: one or more sources the user records came from (for example, Directory Sync or CSV).

4. If you chose a scheduled type, set its timing:

   • On a relative date: enter a Threshold (a whole number from 1 to 100, and values outside the range are rejected when you save) and a Period of Days, Weeks, Months, or Years, then set a Trigger Time. The policy runs daily at that time and anonymizes data older than the threshold.
   • On a fixed date: set the Anonymization date range (a Start date and End date) and a Trigger Time. The end date must be in the past, and the start date must be after January 1, 2000.

   Select a Trigger Time in 30-minute steps. The list uses a 12-hour clock.

5. (Optional) Add exemptions. See Exempt users from a policy.

6. Under 2. Select fields to be anonymized, select the check box for each field to anonymize. At least 1 field is required. Username, LastName, and FirstName are selected by default. For the full list, see Anonymizable fields reference.

7. Review the Summary, which describes in plain language what the policy does and updates live as you fill in the form. For example, "Daily at 01:00 AM we will anonymize Username, LastName, FirstName fields of users matching the following criteria Country = [United Kingdom, Spain] older than 12 Months."

8. Select Save.

Note

If you save a policy with no criteria, Anonymization warns you and asks you to confirm. The warning reads "Without selection criteria, this policy will anonymize all users in the system."

Choose which fields to anonymize

Anonymization can process 14 user fields, listed in the form by their internal names (for example, FirstName, MobilePhone, UnifiedUsername). Select only the fields that are personal data for your purpose. The rest are left untouched so that reports keep as much detail as your obligations allow. The Username and UnifiedUsername fields are hashed with a random value each run, so an anonymized username differs between runs by design. See What "anonymize" means and the Anonymizable fields reference.

Exempt users from a policy

To keep specific users' data from being anonymized, such as service accounts or users under a legal hold, add them as exemptions. Exemptions preserve a user's data even when the user matches a policy's criteria.

1. In the policy form, under Exemptions, select Add Exemption.

   The following screenshot shows the Exemptions dialog:

   The Exemptions dialog. Users selected here are never anonymized by the policy.

2. Select the check box for each user to exempt. Use the search box and column filters to find users by username, first name, last name, email (the column is labeled Email Name), or country.

3. Select Confirm.

To review or change the exemptions, select the link the form then shows, such as 3 exemptions applied (the wording stays plural even for a single user). The dialog reopens with the prompt "Uncheck Item To Remove It From The Exemptions." Clearing every user in the dialog removes all exemptions.

Note

Exemptions apply to individual users only, not to groups. An exempted user is skipped even if they match every other criterion.

Edit a policy

To edit a policy:

1. On the Anonymization page, find the policy and select the edit icon.
2. Change the criteria, timing, fields, or exemptions.
3. Select Save.

Note

You cannot change a policy's name or type after it is created. Both are read-only when you edit. To change either, duplicate the policy or create a new one.

Duplicate a policy

Duplicate a policy to reuse its settings as the starting point for a new one. To duplicate a policy:

1. On the Anonymization page, find the policy and select the duplicate icon.

2. Adjust the new policy, including its name.

   The form opens as a new policy, pre-filled from the original and named Copy of - <original-name>, where <original-name> is the name of the original policy.

3. Select Save.

Turn policies on or off

Turning a policy off pauses it: it stays in the list but does not run again until you turn it on. Existing anonymized data is unaffected. To turn policies on or off:

1. On the Anonymization page, select the check box for one or more policies.

2. Select the toggle button.

   The button is a single toggle whose label depends on the selection. It reads Enable (and enables everything selected) only when every selected policy is disabled. Otherwise it reads Disable and disables everything selected. To bulk-enable a mixed selection, disable it first or select only disabled policies.

Delete policies

To delete policies:

1. On the Anonymization page, select the check box for one or more policies.

2. Select Delete.

3. In the Delete Anonymization Policies dialog, confirm the deletion.

   The dialog reads "The selected policies will be permanently deleted and cannot be recovered."

Deleting a policy is permanent

Deleting a policy cannot be undone. It does not restore data that the policy already anonymized, because anonymization itself is irreversible.

Run a single anonymization

A single anonymization is a one-time run that you start yourself, rather than a saved policy. Use it for one-off requests and immediate actions. It comes in two forms. The following table lists them:

Form	What it anonymizes	Reversible	Kept in history
Broad	The fields you select, for users who match criteria you define.	No	90 days
Absolute	Every field, for the specific users or groups you select, and removes them from Users and Groups.	No	Permanently

Only administrators can run a single anonymization. To open the page, select Single Anonymization on the Anonymization page. The page opens with Absolute preselected, so select Broad if you want the lighter form. If you leave the page with unfinished changes, an Unsaved Changes dialog asks whether to save, discard, or stay.

Run a broad single anonymization

A broad single anonymization is the one-time equivalent of a policy: it anonymizes the fields you choose for matching users, once. The following screenshot shows the Single Anonymization page in Broad mode:

A broad single anonymization scoped by country and date range. The Summary restates exactly what will run.

1. On the Single Anonymization page, under 1. Select anonymization type, select Broad.

2. Set the criteria for the users to anonymize: Countries, Departments, Group, and Source. As with policies, a user must match every criterion you set.

3. (Optional) Turn on Enable date range and set a start and end date to limit the run to data in that period.

4. (Optional) Add exemptions to preserve specific users.

5. Under 2. Select fields to be anonymized, select the fields to anonymize. Username, LastName, and FirstName are selected by default.

6. Review the Summary.

7. Select Run.

   When at least one criterion is set, the run starts immediately, with no confirmation dialog.

Note

If you run a broad anonymization with no criteria, a Broad Anonymization dialog warns you and asks you to confirm. The warning reads "Without selection criteria, this policy will anonymize all users in the system."

A date range skips the all-users warning

A date range alone counts as a filter: a broad run with Enable date range on but no user criteria runs without the all-users warning, and anonymizes every user with data in that period. Set at least one user criterion unless you mean to anonymize everyone.

Run an absolute single anonymization

An absolute anonymization fully erases the identity of specific people. It anonymizes all fields for the users or groups you select, and removes those users from Users and Groups. Use it to satisfy an erasure request. The following screenshot shows the Single Anonymization page in Absolute mode:

Absolute mode: pick users or groups, all fields are locked as selected, and a warning spells out the consequences.

1. On the Single Anonymization page, under 1. Select anonymization type, keep Absolute (it is preselected when the page opens).

2. In the selector, select Users or Groups, then select the check box for each user or group to anonymize. Use search and filters to find them. The users grid shows User Name, First Name, Last Name, Email Name, and Country. The groups grid shows Group Name, Status, and Source.

3. Check that the field check boxes are selected and locked.

   An absolute run anonymizes all fields, so you do not choose fields. In place of the Summary, a warning box states: "Anonymization permanently hides all entity data. Selected entities will be removed from 'Users and Groups,' and this action cannot be undone!"

4. Select Run. The button stays disabled until you select at least one user or group.

5. In the Absolute Anonymization confirmation dialog, confirm to proceed.

   The dialog reads "Confirm to run absolute anonymization. Anonymized data in Users and Groups Service will be permanently deleted in a week."

Absolute anonymization cannot be undone

The selected users are removed from Users and Groups, and their anonymized data in Users and Groups is deleted about a week after the run. Absolute runs are the only anonymization records kept permanently in History.

Monitor anonymization runs

The History page records every anonymization run, from scheduled policies and from single anonymizations, with live progress and results.

View history

The following screenshot shows the History page:

The History page records every run. The Anonymized users count of a completed run opens its per-user list.

The following table lists the columns of the history list:

Column	Description
Policy Name	The policy that ran. For a closed-session run that several policies matched, all their names appear together. For a single broad or absolute run, the cell is empty.
Type	The type of run, shown by its internal name, for example SingleBroad, SingleAbsolute, ScheduledRelativeDate, ScheduledFixedDate, or a closed-session type such as ClosedLicenseSession or ClosedProcessSession.
Anonymized Fields	The number of fields anonymized, or All users' data when every field was anonymized.
Started at	When the run began.
Ended at	When the run finished.
Anonymized users	The run's progress or result. See the following states.

Filter by Policy Name or Type: select the filter toggle in the toolbar to reveal the column filters. Switching the toggle off clears any filters you applied. Select Refresh to reload the latest data. The search box highlights matching text in the rows already loaded, and it does not search other pages.

Note

An On sessions closed policy that is turned on writes one history row for each session it anonymizes, with an Anonymized users count of 1. A busy policy therefore produces many rows rather than one aggregated run.

Track progress in real time

The Anonymized users column reflects each run's live state:

State	What it means
In Progress…	The run is under way. A percentage is not available.
In progress - N%	The run is under way, with a live percentage and progress bar.
A number (for example, 128)	The run finished, having anonymized that many users.

Progress updates automatically while you watch the page. When a run reaches 100%, the row refreshes to show the final count. Small runs can finish within a second, going straight to the count.

See who a run anonymized

To see who a run anonymized, select the anonymized-users count of a completed run other than an absolute one. This opens the Anonymized Users dialog. It lists the users the run anonymized, with their username, first name, last name, email, and country, under a line that names the run and when it ended. The search box highlights matching text in the list. The following screenshot shows the dialog:

The Anonymized Users dialog shows exactly who a run anonymized.

Note

Absolute runs do not keep a per-user list, so the count for an absolute run is not selectable.

The list holds the original details

The per-user list records the users' details as they were before the run, so you can still recognize who was anonymized. This record is itself personal data. It is kept for 90 days and then removed automatically. See Data retention.

Data retention

Anonymization keeps history according to the type of run:

• Absolute single anonymizations: kept permanently, for compliance and audit.
• All other runs: scheduled policies, closed-session runs, and broad single anonymizations, and their per-user detail, are kept for 90 days, then removed automatically.

This retention applies to the history records, not to the anonymized data itself. Anonymization is permanent regardless of how long its history is retained.

Safeguards and restrictions

Anonymization includes safeguards against irreversible mistakes:

• The OpenLM_Everyone group cannot be used. Because it contains every user, it is blocked from policies and from both broad and absolute single anonymizations, and it does not appear in group pickers (the OpenLM_Groups system group is hidden from the pickers as well). This prevents anonymizing the entire organization at once.
• A policy or broad run with no criteria matches everyone. Anonymization warns you and requires confirmation before it proceeds. The warning reads "Without selection criteria, this policy will anonymize all users in the system." A broad run whose only filter is a date range is an exception and does not trigger this warning. See Run a broad single anonymization.
• Absolute anonymization requires confirmation and clearly states that it is permanent.
• Anonymization is irreversible. It has no undo and no key to restore original values. Confirm your criteria and field selection before you run.

Reference

This section lists the fields, policy types, session sources, rules, and roles that Anonymization uses.

Anonymizable fields reference

Anonymization can process the following 14 user fields, listed here as the form shows them. Username, LastName, and FirstName are selected by default in new policies and broad runs. The following table lists the fields:

Field (as shown)	Notes
Country	None
Department	None
Email	None
FirstName	Selected by default.
LastName	Selected by default.
MobilePhone	None
Office	None
Password	None
Phone	None
Title	None
UnifiedUsername	Hashed with a random salt. The result differs each run.
Username	Selected by default. Hashed with a random salt. The result differs each run.
Description	None
DisplayName	None

All fields except Username and UnifiedUsername are hashed deterministically, so the same value always produces the same result. Salted values are 80 characters long, and deterministic values are 64.

Policy types reference

The following table lists the policy types:

Type	Shown in lists as	Trigger	Timing controls
On sessions closed	ClosedSessions	Runs whenever a matching user's session closes.	None.
On a relative date	RelativeDateRange	Runs daily and anonymizes data older than a threshold.	Threshold (1–100), Period (Days, Weeks, Months, Years), and Trigger Time.
On a fixed date	FixedDateRange	Runs daily and anonymizes data within a fixed date range in the past.	Start date, End date (both in the past, with the start date after January 1, 2000), and Trigger Time.

Session sources reference

The On sessions closed policy type reacts to closed sessions from the following OpenLM sources:

• Dongle Monitoring devices
• Touchpoint events
• Process sessions
• Monitored sessions
• Denials
• Disposable tokens
• Monitored allocations

Rules and limits

The following table lists the rules and limits:

Rule	Detail
Policy name	Required, and unique within your organization. Cannot be changed after creation.
Fields to anonymize	At least 1 is required.
Relative-date threshold	A whole number from 1 to 100, validated when you save.
Fixed-date range	Both dates are required. The end date must be in the past, and the start date after January 1, 2000.
Trigger time	Chosen from 30-minute steps on a 12-hour clock with AM or PM. Stored and run in UTC.
Group criterion	Matches the selected groups' direct members only.
OpenLM_Everyone group	Cannot be used for any anonymization.
Exemptions	Individual users only.

Roles reference

The following table lists the roles and their access:

Role	Access
Anonymization administrator (Anonymization_Admin)	Full read and write access to policies, single anonymizations, and history. Account administrators have the same access.
Anonymization viewer (Anonymization_Viewer)	Read-only access to the policy list and History. Cannot create, change, delete, or run anything.

Frequently asked questions

This section answers common questions about reversing, hashing, run types, and History.

Can I reverse an anonymization?

No. Anonymization replaces values with irreversible hashes, and it has no key or undo. Before you run a policy or a single anonymization, confirm the criteria and the fields you selected.

Why does the same username produce a different value each time?

The Username and UnifiedUsername fields are intentionally hashed with a random salt so that each run produces a unique value. This prevents conflicts in Users and Groups, where usernames must be unique, if a name is reused after an earlier user was anonymized. All other fields are hashed deterministically and produce the same value each time.

What is the difference between a policy and a single anonymization?

A policy runs automatically and repeatedly whenever its trigger condition is met. A single anonymization is a one-time run you start yourself. Both appear in History.

What is the difference between broad and absolute anonymization?

A broad anonymization hides only the fields you select, for users who match your criteria. An absolute anonymization hides all fields for the specific users or groups you select and removes them from Users and Groups. Broad runs are kept in History for 90 days, and absolute runs are kept permanently.

Why is the user still in Users and Groups after a broad run?

This is by design. Policies and broad runs anonymize the user's details in the collected usage data. They do not rename or remove the user's entry in Users and Groups. Only an absolute anonymization changes Users and Groups: it removes the selected users, and their anonymized data there is deleted about a week later. See What data is affected.

Why can't I select the OpenLM_Everyone group?

OpenLM_Everyone contains every user, so it is blocked from anonymization to prevent anonymizing your whole organization at once. Target users with more specific criteria or groups instead.

Why did a run disappear from History?

History for everything except absolute single anonymizations is kept for 90 days and then removed automatically. Absolute runs are kept permanently. See Data retention.

Why can't I create or run anything?

The viewer role is read-only, so you can't create or run anything with it. Ask your OpenLM administrator for the Anonymization administrator role. If you see a "not enough permissions" message with no interface, you have neither role.