The Customer Admin Role
What is the Customer Admin role?
The Customer Admin role is a platform role that gives designated users access to the System Administration workspace. It unlocks a set of advanced management capabilities while leaving all existing governance rules and access controls fully in effect.
What can I do with the Customer Admin role?
The role gives you access to:
- System Administration workspace — grant or revoke the admin role for other users
- Global system actions — edit field data, change record status, change the responsible user, and archive or unarchive records directly from any record detail view
- Bulk update user fields — reassign user fields across multiple records at once via the admin workspace
- UI and form translations — manage and preview language labels across the platform
- Note deletion — delete notes written by yourself or others (no additional configuration required)
Who should have the Customer Admin role?
The role is intended for a small, trusted group — typically Compliance Managers or equivalent superusers who currently contact GAN Support to manage bulk updates, status corrections, translations, or similar tasks. We recommend 2–5 users per account, and always have at least two admins so access can be managed if someone leaves.
How do I get the Customer Admin role set up?
The first admin user for your organization must be set up by GAN Integrity. Contact your Customer Success Manager to get this enabled. Once the first admin is in place, they can grant or revoke the role for other users directly from the System Administration workspace — no GAN involvement needed for subsequent changes.
Does having the Customer Admin role give me access to more records?
No. The role does not grant access to any additional records. You can only take admin actions on entities you can already see. Your existing governance settings and record-level permissions remain fully in effect.
Are admin actions logged?
Yes. Every admin action is audited — it is recorded in the audit history and reflected on the relevant record, just like any other action in the platform.
Editing Records and Field Data
Can I update field values on a record that has already been submitted?
Yes. Customer Admins can use the “Edit field data” system action to update fields that have already been populated on any accessible record. This is designed for edge-case corrections — for example, fixing an incorrect risk rating, updating a third-party category that was set in error, or correcting a field entry before the next step in the process runs.
Will editing a field trigger workflow logic, notifications, or approval rules?
No. System admin edits bypass all workflow logic. Changing a risk rating will not apply auto-approval rules. Changing a status will not trigger downstream steps or send notifications. This is intentional — admin actions are for corrections, not for advancing the process.
Are there fields I cannot edit?
Yes, there are a few categories of fields that cannot be edited via the admin workspace:
System-owned fields — fields like “Created at”, “Updated at”, and “Created by” are managed by the platform and cannot be changed.
Read-only (referenced) fields — some fields exist on one record and are displayed in read-only on a connected record. These will not appear in the edit panel. To update this type of field, you need to navigate to the source record and edit it there (for example, a field on a mitigation record that is displayed on a connected disclosure, or a field on an assessment that appears on a connected evaluation).
Unpopulated fields — if a field is empty (for example, no comment was ever added), the edit feature cannot be used to populate it for the first time. It can only update fields that already have a value.
If a field is populated on more than one connected record, do I need to update each one separately?
Yes. Edits apply to a single record at a time. If the same field appears and has been independently populated across multiple connected records, you will need to update each one individually.
Status Changes and User Assignments
Can I change the status of a record?
Yes. The “Change status” system action lets you manually move a record to any status, bypassing normal workflow triggers. This is useful when a record has been moved to the wrong status due to a process error and needs to be returned to its previous state.
I assigned the wrong responsible user on a record. Can I fix it?
Yes. Use the “Change responsible” system action to reassign the responsible user on any accessible record without going through the standard workflow. This can also be granted as a scoped permission to specific users or access groups without giving them the full Customer Admin role — see the Scoped Permissions section below.
A new team member needs access to records created before they joined. How do I handle this?
There are two parts to this:
Routing logic going forward — to update auto-routing rules so new cases are automatically assigned to the new user, contact GAN Support to adjust the workflow configuration.
Historic records — to retroactively assign the new user to records created before their access was granted, use the Bulk Update of Users feature in the admin workspace. Previously this required engineering support; it can now be done directly by a Customer Admin in a fraction of the time.
Can I archive or unarchive records?
Yes, with one exception: Archive/Unarchive is not available for TPRM (Third-Party Risk Management) records due to the complex connected record logic in that module. For all other modules, the action is available from the record’s actions dropdown.
Note that archiving is non-cascading: archiving a record does not automatically archive connected records. For example, archiving a mitigation will not archive its connected disclosure — that would need to be archived separately if required.
Scoped Permissions (Without the Full Admin Role)
Can I give a user the ability to archive records or change the responsible user without making them a full Customer Admin?
Yes. The Archive/Unarchive and Change Responsible actions can be enabled for specific users without granting the full Customer Admin role. This can be done at two levels:
Record level — the user assigned in a specific role on a record (e.g. Compliance Reviewer or equivalent) can be given these permissions for that record only.
Governance level — all users in an access group that already controls their record visibility. Access groups can be scoped to all records of a given type (for example, all disclosures), or to a filtered subset (for example, all disclosures where conflict type is "outside work," or all gift and hospitality requests where the recipient country is Germany). If users are already receiving record access through an access group, that same group can also be configured to grant them the Change Responsible and Archive/Unarchive actions for those records.
This access is app-specific and does not include access to the System Administration page or any other Customer Admin capabilities.
Can users bulk-update user fields without the full Customer Admin role?
Yes. The Bulk Update of Users capability can be granted at the governance level (for all users in a specific access group) without the full Customer Admin role. It is not available at the record level for scoped grants.
Users will only ever be able to update records they already have access to — filters can further restrict which records are included in a bulk update.
Notes and Other Features
Can I delete a note that was added by mistake or shared with the wrong audience?
Yes. Users can delete notes they authored. Customer Admins and GAN Admins can also delete notes written by other users within the platform. There is no configuration required — this is available to all users immediately.
One exception: notes submitted via external submission portals cannot be deleted, in order to protect the integrity of information submitted through those channels.
When a note is deleted, the note thread will indicate that a note existed and has been removed, rather than silently disappearing.
What happens to in-progress workflows when I make admin changes?
Admin actions are designed specifically to not interfere with workflow logic. Status changes, field edits, and user reassignments made via the admin workspace do not trigger notifications, advance workflow steps, apply business rules, or change any automated routing. The record is updated as corrected, and the process continues from that point forward as normal.
Limitations and When to Contact GAN Support
What can’t I do with the Customer Admin role?
The Customer Admin role is a powerful self-service tool, but some things still require GAN Support:
Updating workflow configuration — changes to auto-routing logic, workflow steps, approval rules, or process design require GAN Support involvement.
Updating empty/unpopulated fields — the edit feature can only modify fields that already have a value.
Enabling scoped permissions — granting Archive/Unarchive, Change Responsible, or Bulk Update of Users as standalone permissions (without the full admin role) requires GAN Admin assistance.
Archiving TPRM records — not available due to complex connected record logic.
Modifying system-owned fields — created/updated timestamps and similar system fields cannot be changed.
When should I contact GAN Support instead of using the admin workspace?
Contact GAN Support when:
You need to change how the workflow is configured (routing rules, step logic, approval conditions).
You need to enable scoped permissions for specific users or access groups.
You encounter an issue that cannot be resolved through the available admin actions.
For day-to-day corrections — field edits, status changes, user reassignments, bulk updates — the admin workspace is designed to handle these without GAN involvement.