Anonymization

Anonymization lets you permanently remove personal user data from OpenLM usage records to meet privacy and data-protection obligations, such as the General Data Protection Regulation (GDPR). 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 has collected.

What Anonymization does

OpenLM collects usage data — license checkouts, process sessions, denials, dongle activity, and more — 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.
• Target only the users a rule of privacy applies to, 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 — 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 2 entities, which also correspond to the 2 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 disable a policy 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, 2 anonymized sessions that belonged to the same person still group together. Two fields, Username and UnifiedUsername, are hashed with a random salt 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 user name 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 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, removes the selected users from Users and Groups, and their anonymized data in the Users and Groups Service is permanently deleted about a week later. Use it when the person must disappear from the platform entirely, such as for a "right to be forgotten" request.

What triggers a policy

A policy's type controls when it runs. All 3 types anonymize the fields you select for the users who match the policy criteria; they differ only in timing.

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, 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

The trigger time is interpreted in the time zone configured in UI Configurations, converted to UTC when the policy is saved, and 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 the OpenLM Platform. The On sessions closed type responds to closed sessions from dongle monitoring, process sessions, touch point 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 together: 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 to keep in mind:

• 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 — 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.

What you need

• Access to the 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 being collected (for example, through Broker and the Workstation Agent), so that there are sessions to anonymize.

Roles and permissions

What you can do in Anonymization depends on your assigned role.

Role	What you can do
Anonymization administrator (Anonymization_Admin)	Full access. View policies and history, create and edit policies, enable and disable them, 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, enable, disable, or delete policies, and cannot run a single anonymization.

Viewers still see the administrator controls — Add Policy, Single Anonymization, the enable/disable and delete buttons, and the per-row edit and duplicate icons — but the actions are blocked: selecting them does nothing.

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

Key terms

The following terms 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

Open Anonymization

Anonymization runs inside the OpenLM Platform in your web browser, at an address of this form:

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

where cloud-XX is your OpenLM cloud instance (for example, cloud-us). You can also open it from the OpenLM Platform app launcher.

Anonymization uses the OpenLM Platform single sign-on. There is no separate login form: if you are not already signed in, your browser is redirected to the OpenLM login page and returns you to Anonymization afterward. To sign out, open the account menu in the header and select Log Out.

Explore the interface

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 path through Anonymization looks like this:

1. Decide what is personal. Identify the user fields that count as personal data for your obligations.
2. Create a policy. On the Anonymization page, add a policy that anonymizes those fields for the right users on the right trigger.
3. Exempt anyone who must be preserved (optional). Add exemptions for users whose data you must retain.
4. Handle one-off requests with a single anonymization. Run a broad or absolute anonymization when you need to act once rather than on a schedule.
5. Monitor results. On the History page, confirm that runs complete and review which users were anonymized.

Work with anonymization policies

The Anonymization page lists every policy you have defined and is where you create, edit, and manage them.

View policies

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

Each row on the policy list shows the following:

Column	Description
Policy Name	The name of the policy. A disabled policy is marked with a red 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 enable, disable, or 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 Add Anonymization Policy form opens.

   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. Leave the toggle set to Enabled so the policy is active, or set it to Disabled to save it paused.
   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 — 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; 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.

   The Trigger Time list offers times in 30-minute steps on 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 — "Without selection criteria, this policy will anonymize all users in the system." — and asks you to confirm.

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 user name differs between runs by design. See What "anonymize" means and the Anonymizable fields reference.

Exempt users from a policy

Exemptions let you preserve specific users' data even when they match a policy's criteria — for example, service accounts or users under a legal hold.

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

   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 user name, first name, last name, email (the column is labeled Email Name), or country.

3. Select Confirm.

The form then shows a link such as 3 exemptions applied (the wording stays plural even for a single user). Select it to review or change the exemptions — 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

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.

1. On the Anonymization page, find the policy and select the duplicate icon.
2. The form opens as a new policy, pre-filled from the original and named Copy of - original name. Adjust it, including the name.
3. Select Save.

Enable or disable policies

Disabling a policy pauses it: it stays in the list but does not run again until you enable it. Existing anonymized data is unaffected.

1. On the Anonymization page, select the check box for one or more policies.
2. Select the enable/disable 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

1. On the Anonymization page, select the check box for one or more policies.
2. Select Delete.
3. In the Delete Anonymization Policies dialog — "The selected policies will be permanently deleted and cannot be recovered." — confirm the deletion.

warning

Deleting a policy is permanent and cannot be undone. Deleting a policy does not restore data that the policy already anonymized — 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 2 forms.

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; 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.

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, then select Run. When at least one criterion is set, the run starts immediately — there is no confirmation dialog.

note

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

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. Always set at least one user criterion unless you really mean 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.

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, choose 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. An absolute run anonymizes all fields, so the field check boxes are selected and locked — 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 run absolute anonymization. Anonymized data in Users and Groups Service will be permanently deleted in a week." — confirm to proceed.

warning

Absolute anonymization is permanent and cannot be undone. The selected users are removed from Users and Groups, and their anonymized data in the Users and Groups Service 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 History page records every run. The Anonymized users count of a completed run opens its per-user list.

Each row shows the following:

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, and note that 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; it does not search other pages.

note

An enabled On sessions closed policy 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 yet 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

For a completed run other than an absolute one, select the anonymized-users count to open the Anonymized Users dialog. It lists the users the run anonymized, with their user name, 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 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.

info

The per-user list records the users' details as they were before the run — that is how 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 are 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 — "Without selection criteria, this policy will anonymize all users in the system." — and requires confirmation before it proceeds. Exception: a broad run whose only filter is a date range 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

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.

Field (as shown)	Notes
Country
Department
Email
FirstName	Selected by default.
LastName	Selected by default.
MobilePhone
Office
Password
Phone
Title
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
DisplayName

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

Policy types reference

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; start 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
• Touch point events
• Process sessions
• Monitored sessions
• Denials
• Disposable tokens
• Monitored allocations

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 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

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

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 user name 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 user names 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; absolute runs are kept permanently.

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

That 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?

You most likely have the viewer role, which is read-only. Ask your OpenLM administrator for the Anonymization administrator role. If you see a "not enough permissions" message with no interface, you have neither role yet.