Roles, Auditor & sandbox

Last updated: 2026–05-27

Application detail combines UI role gates (hide controls) with API authorization (check_resource_access on mutations). Users should not rely on hidden buttons alone for compliance—backend still enforces tenant scope.

---

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 API	No
Application tab edit/revert	If allow_edit	If allow_edit	If allow_edit*	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	Policy†	No
SMS tab	If tenant SMS + role	If tenant SMS + role	If Manager/Admin	No
Arc AI tab	If arc_ai_enabled	If enabled	If enabled	No
Add Offer	Admin	If UW data exists	View only	No

*Auditor may still be blocked by allow_edit from server.
†Confirm tenant policy; header doc actions on Docs tab are not uniformly wrapped in Auditor hides in v2.

---

Auditor — what to expect

Auditors are intended for read-only compliance review:

1. No status changes, OTP, or Cashmax scheduling in header.
2. No new internal notes.
3. No email send actions.
4. No task mutations.
5. Assignee appears but is not clickable.

Warning: Auditors can still download PDFs and may open integration payloads or encrypted fields if your tenant grants decrypt—align with your compliance model.

---

Applicant role

Applicants opening an application detail in the agent shell (unusual but supported in code):

• Tasks tab removed from navigation.
• Other restrictions follow applicant portal permissions and allow_edit.

---

Analyst nuances

• Add Offer only when underwriting offer variables exist to populate the modal.
• AddApplicationTags dropdown may hide “create new tag” catalog actions (HideForRoles for Analyst) while still allowing applying existing tags.

---

Sandbox environment

When working in sandbox (non-default DB routing):

Area	Behavior
Webhooks from Update Status	Queued with db_name="sandbox"
Async emails (e.g. withdrawn, continue app)	Sandbox queue
Data shown	Sandbox copy of applications—does not affect production
Activity/integration	Reflects sandbox executions only

Warning: Approving or declining in sandbox does not move production applications. Train agents to check the environment badge elsewhere in the shell before status changes.

---

List vs detail permissions

Agent dashboard list APIs scope applications by role (Tenant Admin, Auditor, Manager see tenant-wide; Analyst parent vs sub-tenant rules; others see assignments). Opening detail still runs check_resource_access on each mutation even if the user reached the page.

---

Implementation notes

• UI uses HideForRoles wrapper and hasSomeRole checks (usePermissions).
• SMS tab additionally requires tenant_sms on the current user object.
• Arc AI requires arc_ai_enabled in session cookie payload.
• Server stage changes documented in UpdateAppStageAPIView reset approve/decline/request_docs flags before applying the new action.

---

← Application detail hub