My workspace

My workspace is your personal, private staging area within a project. When you create, edit, or delete an attribute, attribute connector, policy, or cache profile, the change is saved to your workspace first and is not applied to the shared project state until you explicitly save it. This lets you work at your own pace and build up multiple related changes without affecting your teammates or the live project.

How it works

• Every change you make to an in-scope artifact is saved to your workspace.
• Multiple changes accumulate in the same workspace until you save them to the project or discard them.
• If you edit an artifact again while it already has a staged change, the previous staged version is overwritten with your latest edit.
• Other project members continue to see the last state saved to the project. Your staged changes are private to you and are not visible to anyone else, including Tenant admins. The only exception is a Project admin, who can also see and handle the workspaces of machine-to-machine (M2M) clients. See Client workspaces.
• Your workspace persists across sessions. If you close your browser and come back later, your staged changes are still there.

note

Each project member (user or M2M client) has at most one workspace per project they belong to. The workspace is created when you stage your first change and removed when you save or discard it.

Accessing My workspace

Access to My workspace depends on your project role:

	Domain viewer	Project viewer	Project editor	Project admin
Access My workspace	❌	✔️	✔️	✔️
Handle client workspaces	❌	❌	❌	✔️

Read the Project roles section for details on each role.

Scope

My workspace currently covers:

• Attributes (Dictionary)
• Attribute connectors
• Policies
• Cache configuration

Domains and Policy insights are not covered by My workspace. Changes to these are applied immediately.

Imported changes

When you import attributes, attribute connectors, or policies from a file, the imported items are saved to your workspace as pending changes, the same as changes you make manually. Review them here, and save them to the project or discard them.

• If you already have a pending change for the same item, the import replaces it.
• Discarding the workspace removes everything the import added, across all artifact types, along with all other staged changes.
• Items that the import skipped or failed to apply are not staged. They appear only in the import results message.

Visual indicators

While you have staged changes, a vertical orange line marks the affected items:

• In the Dictionary list, next to any attribute you've created or edited.
• In the Attribute connectors list, next to any attribute connector you've created or edited.
• In the Policies editor's ALFA resources list, next to any file with staged changes.
• In the Cache configuration list, next to any profile you have edited.

When you open the create/edit window for an artifact that already has a staged change, the save button indicates that your changes will be saved to your workspace rather than applied directly to the project.

note

Items staged for deletion are hidden from their respective list views until the deletion is saved to the project or discarded.

note

These indicators are private and only you can see them. Other project members see each list as it exists in the shared project state.

Authorization Hub also shows count indicators so you can track staged changes without opening My workspace:

• A persistent My workspace: # changes indicator in the top bar, shown whenever you have staged changes anywhere in the project.
• A count badge next to each artifact type in the left navigation panel (Dictionary, Attribute connectors, Policies, Cache configuration), showing how many staged changes you have of that type.

note

Both indicators are informational only and private to you. They update in real time as you add, save, or discard changes.

Reviewing your changes

When you have staged changes, they are grouped into sections by artifact type (Dictionary, Policies, Attribute connectors, Cache configuration) each showing a count. A summary banner at the top shows the total number of staged changes. You can filter the view to a single artifact type, or view all changes together.

Each item in the list shows:

• The change type: created, updated, or deleted.
• A relative timestamp.
• For attributes, attribute connectors, and cache configuration: an inline, one-line description of the change (for example, "Datatype: from string → ipAddress").
• For policies: a Compare changes link, described below, instead of an inline description.
• In a client's workspace: who staged the change.

You can discard individual items directly from this view, or clear your entire workspace at once. See Discarding changes below.

Comparing policy changes

As ALFA files can be large, policy changes aren't summarized inline. Instead, click Compare changes next to a staged policy file to open a side-by-side diff dialog:

• Yours - my workspace: your staged version.
• Current - project state: the version currently live in the project.

The comparison also works correctly if you've renamed the file since staging the change. You can close the dialog at any time without taking any action.

Saving to project

When you're ready to share your work, click Save to project in the top right of the My workspace view. The Save to project dialog opens with an optional Description field. Click Save to apply all of your staged changes to the shared project state in a single operation.

note

Either all changes are applied or none are, ensuring the project is never left in a partially updated state.

If none of your changes conflict with changes made by other project members, the save goes through and you see a success message. Your changes are immediately visible to all other project members, and My workspace is cleared.

Because your workspace is private, it doesn't automatically stay in sync with the shared project state. If another project member has changed any of the artifacts you are saving since you started editing, nothing is applied and the Review your changes dialog opens instead. It lists your staged changes in two groups:

• Conflicts: items where the artifact has changed in the project since you staged your edit. These must be resolved before you can continue. See Resolving conflicts below.
• No conflicts found: your other staged changes, which can be saved as-is. This group only appears alongside at least one conflict.

Each item is identified by its artifact type, name, and change type (created, updated, or deleted). A progress indicator tracks how many conflicts are still pending, and Continue stays disabled until it reaches zero.

Once all conflicts are resolved, click Continue. The Save to project dialog opens again, keeping the description you entered and adding a Back button that returns you to the review. Click Save to apply all of your staged changes.

You can click Cancel in either dialog at any point to back out without saving, so you can edit your changes manually before trying again.

If the save fails, none of your changes are applied, and everything remains staged in My workspace so you can try again.

If the save is rejected because some staged changes are not valid, an alert explains why. Click Details in the alert to see the reasons, then correct or discard the changes concerned. This mostly affects changes staged through the API, which are checked only when you save.

Resolving conflicts

A conflict is detected per artifact, or for policies, per ALFA file (see below): if any part of an artifact has changed in the project since you started editing it, the entire artifact is flagged as conflicting. Authorization Hub never merges changes automatically. You always choose how each conflict is resolved.

Click a conflicting item in the Review your changes dialog to open its comparison view. The header names the artifact, summarizes which fields differ, and shows who changed the project version last and when. What the comparison itself shows depends on the artifact type:

• Attributes: the comparison is shown field by field (data type, category, description, cache profile, namespace, XACML ID), with the fields that differ highlighted.
• Attribute connectors: the comparison is grouped into the connector's own sections, with differing fields highlighted. Settings specific to the attribute connector type appear as collapsible groups within these sections.
• Policies: conflicts are evaluated and resolved per ALFA file, not per policy. Each conflicting ALFA file appears as its own row, labeled with the file name without the .alfa extension, and has its own Keep mine and Keep current choice. A single policy can have some files in conflict and others not. Each conflicting file is shown as a side-by-side, line-numbered diff with ALFA syntax highlighting.
• Cache configuration: the comparison is shown field by field (time to live, max items), with differing fields highlighted.

The comparison also reflects the type of conflict:

• Updated on both sides: the comparison shows the fields that differ.
• Deleted on one side and updated on the other: the deleted side displays "Artifact deleted" with no diff, while the other side shows what changed.
• Created on both sides: you and another project member each created an artifact with the same name. If the project version can't be loaded for comparison, the panel displays "Already in the project" and explains that someone else created the artifact.
• Renamed: the header adds "Renamed to" followed by the new name.

Identical changes on both sides, such as creating matching artifacts or deleting the same artifact, are not treated as conflicts.

For each conflict, choose one of the two options shown above the comparison:

• Keep mine: save your workspace version, replacing the current project version.
• Keep current: discard your change and keep the current project state.

Once you choose, the item's status changes from PENDING to show which side was kept, and the dialog's progress indicator updates.

info

Non-conflicting items don't need a resolution. Selecting one opens a read-only panel showing what will be created, updated, or deleted.

If another user updates an artifact while you are resolving conflicts, Authorization Hub detects this change when you save and applies no updates. Instead, the diff refreshes with the latest changes, and you are prompted to review and resolve the conflict again. This prevents changes from being silently overwritten.

Discarding changes

If you want to undo your work, you can:

• Discard a single artifact's changes from its row in the workspace list, to undo a mistake without affecting your other staged changes. The confirmation step names the artifact you're about to discard.
• Discard all changes to clear your entire workspace at once. The confirmation step shows a generic warning rather than listing each affected artifact individually.

Both actions require you to confirm before the changes are removed. Discarding does not affect the shared project state. It only removes your staged changes and reverts the affected artifacts to their current live version.

warning

Discarding changes cannot be undone.

Client workspaces (Project admins)

A workspace belongs to the user or M2M client that made the change. Changes written with client credentials, whether through the API or by a migration tool, are staged in a workspace held by that client. A client never signs in, so it cannot save or discard that workspace itself. Without a way to reach it, the changes would stay staged and never appear in the project.

Project admins can see and handle every client workspace in the project. The workspaces of other people stay private, and members without the Project admin role only ever see their own workspace.

Switch to a client's workspace

When the project has at least one client workspace with staged changes, a DRAFT CONTEXT bar appears below the header.

1. Open the dropdown in the bar. It lists My workspace first, followed by one entry per client, named after the client.

   note

   Clients with no staged changes are not listed.

2. Select a client.

   A message confirms that you are now working in that client's workspace.

3. To go back, click Leave draft or select My workspace.

While you are in a client's workspace:

• The bar turns dark and states that changes are staged to the client's work and audited under your name.
• You are taken to the start of the section you were in, so no detail view from your own workspace stays open.
• The My workspace: # changes indicator and the counts in the left navigation show the client workspace's changes instead of yours.
• The My workspace page is titled after the client.

note

If you have unsaved changes in the policy editor when you switch, you are asked to confirm. Switching without saving discards them.

If the workspace you are viewing is saved or discarded by someone else, you are returned to your own workspace with a warning. The list of workspaces refreshes automatically about once a minute.

Review and correct a client's changes

Review the client's staged changes in the My workspace page as you would your own, including Compare changes for policies. Each change also shows who staged it, because a client workspace can hold both the client's work and your corrections. In the Policies editor, files staged in a client workspace show a dark marker, and hovering over a file names who staged it.

You can stage further changes into a client's workspace. While you are in it, anything you create, edit, or delete in the Dictionary, Attribute connectors, Policies, or Cache configuration is staged there instead of in your own workspace. Use this to correct an incomplete or incorrect change before saving it.

Save or discard a client's workspace

Use Save to project and the discard options exactly as described in Saving to project, Resolving conflicts, and Discarding changes. You can discard the whole workspace or a single artifact from it. Discarding the last remaining change removes the workspace.

A few things work differently from your own workspace:

• Attribution: on save, each change is applied under the person who staged it. The client's changes are credited to the client, and your corrections are credited to you, both in the Activity feed and in the artifact's created by and updated by fields. The client is recorded only as the author of the change set. Neither the UI nor the API shows this.
• Audit: saving, discarding a workspace, and discarding a single artifact are recorded in the audit logs with you as the actor.
• Validation: changes a client staged through the API are validated when you save. If any is not valid, nothing is saved and the alert lists the reasons. Correct the change in the client's workspace, or discard it, and save again.

Changes made through the API

My workspace applies to the API as well. Changes that a user or a M2M client makes to attributes, attribute connectors, cache profiles, and policies through the API are staged in the workspace of that user or client, and applied only when the workspace is promoted. Staged API requests return 202 and are validated when promoted. Read My workspace and the API for details.

A machine-to-machine client has its own workspace in each project. Through the API, a Project admin can also review, promote, or discard the workspaces of the project's clients.