Appearance
Roles, Auditor & sandbox
Application detail pages show different controls to different roles, and sandbox environments let you test status changes and workflows without touching production applications. This page explains what each role can see and do on the application detail screen, and how sandbox keeps test activity separate from real applicant data.
Application detail combines UI role gates (which hide controls) with API authorization (checks run on every mutation, not just on page load). Do not rely on a hidden button as your only compliance control — the backend enforces tenant scope and role permissions independently of what the interface shows.
Role matrix (detail page)
| Capability | Tenant Admin / Manager | Analyst | Auditor | Applicant |
|---|---|---|---|---|
| View tabs (most) | Yes | Yes | Yes | Yes (except Tasks tab hidden) |
| Download PDF | Yes | Yes | Yes | Per app access |
| Update Status, OTP, Schedule | Yes | Yes | No | No |
| Assign application | Yes | Yes | Read-only | No |
| Add/remove tags on app | Yes | Limited catalog create | Yes/No per tag permission | No |
| Application tab edit/revert | If edits are allowed for the app | If edits are allowed for the app | If edits are allowed for the app* | No |
| Notes — add | Yes | Yes | No | No |
| Notes — read | Yes | Yes | Yes | If exposed |
| Email send / compose | Yes | Yes | No | No |
| Tasks — create/edit | Yes | Yes | No | Tab hidden |
| Docs — request/generate | Yes | Yes | Per tenant policy† | No |
| SMS tab | If tenant has SMS enabled and role allows | If tenant has SMS enabled and role allows | If Manager/Admin | No |
| Arc AI tab | If enabled for tenant | If enabled | If enabled | No |
| Add Offer | Admin | If underwriting offer data exists | View only | No |
*An Auditor’s ability to edit an application tab can still be blocked server-side even if the interface allows it. †Check your tenant’s document policy — header document actions on the Docs tab are not consistently hidden for Auditors.
Auditor — what to expect
The Auditor role exists for read-only compliance review:
- No status changes, OTP actions, or scheduling controls appear in the header.
- No new internal notes can be added.
- No email send actions are available.
- No task mutations (create, edit, complete) are possible.
- The assignee name appears but is not clickable.
Auditors can still download PDFs, and depending on your tenant’s decryption settings, may be able to view encrypted fields or integration payloads. Confirm this aligns with your compliance requirements before granting the Auditor role.
Applicant role
An applicant can, in unusual configurations, open an application detail page in the agent-facing shell. When this happens:
- The Tasks tab is removed from navigation.
- All other restrictions follow the applicant’s portal permissions and whether edits are allowed on the application.
Analyst nuances
- The Add Offer action is only available to an Analyst when underwriting offer data already exists to populate the offer form.
- When adding tags to an application, an Analyst may not see the option to create a new tag in the catalog, but can still apply existing tags.
Sandbox environment
Sandbox is a separate, non-production environment used for testing. When you are working in sandbox:
| Area | Behavior |
|---|---|
| Webhooks triggered by a status update | Queued against the sandbox environment |
| Async emails (for example, withdrawn or continue-application notices) | Sent through the sandbox queue |
| Data shown | A sandbox copy of applications — production data is unaffected |
| Activity and integration logs | Reflect only sandbox executions |
Approving or declining an application in sandbox does not change anything in production. Always confirm which environment you are in before making a status change, especially if your team switches between sandbox and production during testing.
Worked example
A tenant admin, Priya, is training a new underwriter, Dana, on the application detail screen before giving her production access.
- Priya opens a test application in sandbox for a Personal Line of Credit applicant with a FICO score of 702 and a requested amount of $15,000.
- Dana, logged in as an Analyst, opens the same application detail page. She sees the Application, Notes, Tasks, and Docs tabs, and can add an offer because underwriting data already exists on the application.
- Dana changes the application status to Approved and sends a decision email from the Email tab.
- Because this is sandbox, the webhook and email are queued against the sandbox environment. Production applications for this tenant are untouched.
- Priya then logs in as an Auditor to show Dana what a compliance reviewer sees: no status controls, no note entry, no email compose button, and the assignee shown as text only, not a clickable link.
This lets Priya train Dana on both the working-analyst view and the compliance-reviewer view without risking any real applicant data.
Use case
A credit union wants its compliance team to review closed applications for QA purposes without being able to alter any application data, and it wants agents to be able to rehearse new underwriting workflows before those workflows go live.
The credit union assigns compliance staff the Auditor role, which blocks status changes, note creation, email sends, and task mutations, while still allowing PDF downloads and read access to most tabs. Separately, it has agents rehearse new decisioning workflows in sandbox, where status changes, webhooks, and emails are all routed to a test environment and never touch production applications or send real communications to applicants.
List vs detail permissions
The Agent Dashboard application list scopes which applications a user can see by role: Tenant Admin, Auditor, and Manager see tenant-wide applications; Analyst sees parent-tenant and sub-tenant applications according to tenant rules; other roles see only applications assigned to them. Opening an application’s detail page does not bypass this — every mutation on the detail page still runs its own authorization check, even if the user was able to reach the page.
Best practices
- Do not treat a hidden button as proof that an action is blocked. The backend enforces permissions independently, but verify your tenant’s configuration if you depend on this for compliance sign-off.
- Use the Auditor role for compliance and QA review, not for staff who need to take action on applications — Auditors cannot change status, add notes, send email, or manage tasks.
- Before approving or declining applications during training or testing, confirm you are in sandbox, not production. Sandbox actions do not affect real applications, but production actions do.
- If you grant an Auditor decrypt access to encrypted fields or integration payloads, confirm this matches your compliance policy — Auditors are not blocked from viewing this data by default.
- For Analysts who should not create new tags, rely on the built-in restriction that hides “create new tag” while still allowing them to apply existing tags — don’t try to replicate this with a separate permission.