Skip to main content
Arcane Compliance uses a three-level role hierarchy to control what each user can see and do in the Auditing Portal. At the top, Organization Administrators manage the organization and its applications. Beneath them, Application Administrators govern compliance workflows within a specific application. Auditors work at the most granular level — creating disclosure requests and reviewing the case data they have been granted access to. Each role builds on a distinct set of permissions, and no role automatically inherits the permissions of another.

Organization Administrator

Manages the overall organization in the Auditing Portal. Creates and configures applications, invites team members, assigns application-level roles, and accesses organization-wide reports and activity logs. Organization administrator permissions are granted at the organization scope and appear in the owner bucket of the portal session.

Application Administrator

Works within one or more application workspaces. Reviews incoming disclosure requests from auditors, approves or closes them, sets case access windows, and assigns auditors to approved cases. Can view application-level activity logs and list or download application reports.

Auditor

Works within an application workspace on cases they have been assigned to. Creates disclosure requests, reviews interpreted transaction data for approved cases, generates transaction reports, and downloads them. Access to transaction data is always case-scoped and time-bound.

Permission reference

Permissions are grouped into four buckets: owner (organization scope), administrator (application scope), auditor (application scope), and common (application scope, available to all application roles).
Permission keyBucketWhat it allows
applications:createOwnerCreate new applications within the organization
applications:readOwnerView the list of applications in the organization
admins:manage_application_administratorsOwnerInvite, remove, and update application administrators
logs:view_activityOwnerView the organization-level activity log
reports:createOwnerGenerate organization-level reports
reports:listOwnerList organization-level reports
reports:downloadOwnerDownload organization-level reports
cases:approve_creationAdministratorReview, approve, and close disclosure requests from auditors
cases:editAdministratorManage case auditor assignments on approved cases
reports:listAdministratorList reports within an application workspace
reports:downloadAdministratorDownload application reports
logs:view_activityCommonView the application-level activity log
cases:createAuditorCreate a new disclosure request
cases:withdraw_pending_requestAuditorWithdraw your own pending disclosure request before it is acted on
reports:view_transactionsAuditorReview interpreted transaction data for assigned approved cases
reports:createAuditorGenerate transaction reports for an approved case
reports:listAuditorList reports within an application workspace
reports:downloadAuditorDownload generated reports
The logs:view_activity permission appears in both the owner bucket (organization scope) and the common bucket (application scope). Organization administrators use it to view organization-wide activity; application-level users use it to view activity within a specific application.

Access hierarchy

Permissions in Arcane are layered. Understanding the three levels helps you configure team access correctly. Organization-level permissions are stored in the owner bucket and control access to the organization owner workspace. They cover cross-application actions like creating applications and viewing organization-wide reports. A user with at least one owner permission sees the organization owner workspace in their portal. Application-level permissions are stored in three buckets on each application assignment: common, administrator, and auditor. A user must have at least one application-level permission to see that application workspace in their portal. Within the workspace, the available actions depend on which permission keys are present in each bucket. Case-level access is the most granular layer. Even if a user holds auditor-level application permissions, they can only open and review cases they have been explicitly assigned to by an application administrator. Case access also carries an expiry window set at approval — once the window closes, the case is no longer accessible regardless of other permissions.
An organization administrator does not automatically have application-level permissions. If you want an organization administrator to also review transactions within a specific application, assign them the relevant application permissions separately.
Case-level data access also respects the disclosure flags set when the case was approved. Holding reports:view_transactions allows you to open a case, but you will only see the specific data fields (such as sender information or withdrawal details) that the administrator enabled when approving the disclosure request.