What is it?
In the ITONICS Platform, access to content is generally governed by global and entity-level roles. However, there are scenarios where specific users need elevated access to a single element (e.g., a specific Trend or Technology) without changing their overall role.
The application gives you individual permission to provide more powerful permissions for specific content elements to other users even if they do not have any global permissions for this entity (e.g. view, edit etc.). Or, vice versa, to request a more powerful permission scheme from another user for a specific content element.
Note: If instead only specific elements of an entity that is accessible by a user group (global view permission) needs to be restricted, the Visibility and Confidential Tab to restrict access is the correct approach.
The Grant and Request Permission features provide a transparent, auditable workflow for managing these element-specific access rights.
How does it work?
Requesting permissions
If you have view access to an element but need higher-level permissions to contribute, you can submit a request directly to the designated approvers.
How to request access?
Navigate to the element detail page.
Click the meatball icon (three dots) in the top right corner.
Select Request Permission.
You will automatically be filled out as the Recipient value
-
In the modal, select the level of access you require
Note: The system enforces a hierarchy. For example, requesting "Edit" will automatically include "View".
You will only be able to select the permission you do not yet own
Optionally add a message providing further context, e.g. reasoning
Click Request when ready
Important rules for requests
Self-request only: You can only request permissions for yourself.
Visibility: You can only request permissions for Edit, Delete, or Rate if you can already View the element.
Confidential tabs: You cannot request access to confidential tabs unless you already have View access to them.
Pending requests: You can only have one active request at a time per element. You can delete a pending request if you change your mind.
Full access: If you already possess all available permissions for an element, the button will be greyed out with a tooltip indicating you have full access.
Granting permissions (for Approvers)
Permitted users can manage access for others. These users can proactively grant or revoke permissions. Note: it is not required to have a pending request to grant access. You can use the Grant Permission modal to:
Search for a user and manually assign View, Edit, Delete, or Rate access.
Revoke Access: You can see a history of granted permissions and remove them at any time. Note: Revoking "View" access will automatically revoke all higher permissions (Edit, Delete, Rate) granted through this tool.
The Approval workflow
System administrators define who can request access and who is responsible for approving those requests.
Defining Approvers: Approvers are set at the entity level:
Go to Settings > Entity Configuration > Permission Configuration.
Navigate to the Approvers sub-tab.
-
Select the users, roles, or groups who should act as the default approvers.
Default: The Application Owner (AppOwner) is assigned by default.
-
Personas: You can select specific users, roles, user groups, contexts, entity-specific user search-/user group search fields, or even the Creator persona to be Approvers for all permission requests for elements of the associated entity type.
Important note: assigned Approvers must not hold the permissions themselves to be able to grant the permission request.
When a user submits a request, all designated Approvers receive an in-system and email notification.
Open the notification and be redirected to the element.
The meatball icon will show a numerical badge (e.g., "1") indicating pending requests.
Select Grant Permission to open the management modal.
-
You will see a list of pending requests with options to Approve or Decline.
Declining: Requires a secondary confirmation to prevent accidental rejections.
First-response logic: If multiple approvers are active, the first decision (Approve or Decline) is final. Other Approvers will receive a notification that the request is "outdated" if they try to act on it simultaneously.
Auditing and logs
To ensure security and transparency, every change made via the Grant/Request Permission feature is logged. Administrators can view these records by navigating to: Settings > Logs > System Logs > Share Permission Changes.
The logs track:
Who requested the permission.
Which permission was requested.
Who approved or declined the request.
When the action took place.
Which element was affected.
And the Status of the request.
Learn how to simply share an element with other users without adding special permissions to it.
Please note: This feature is not available for elements that have the "Draft" status.