Identity and Access Deployment
Identity and access deployment covers the first production administrators, role and department readiness, authentication policy, email-dependent account flows, and license activation. These decisions should be confirmed before the system is opened to business users.
Deployment Identity Decisions
| Decision area | Required planning | Go-live impact |
|---|---|---|
| Initial administrators | Name the customer-owned administrators who will receive system access after installation. | Avoids shared or unmanaged production administration. |
| Role model | Confirm built-in roles, custom role requirements, and approval ownership for permission changes. | Determines which users can upload, approve, share, administer, and audit content. |
| Department model | Confirm initial departments and folder ownership expectations. | Affects folder visibility, workflow routing, and permission-based access. |
| Authentication policy | Confirm password policy, session policy, and MFA expectations. | Aligns DeskDox access behavior with customer security policy. |
| Email dependency | Confirm SMTP before relying on invitations, password reset links, notifications, and document email. | Prevents account and sharing workflows from failing after rollout. |
| License activation | Confirm online or offline activation process and owner. | Ensures licensed features are available before production users start. |
Initial Administrator Access
Production administrator access should be issued to named customer owners. Shared credentials should be avoided. If a temporary implementation account is required during deployment, agree its expiry, ownership, and removal plan before go-live.
Record the following in the deployment handover notes:
- Named application administrators.
- Named infrastructure or Docker host administrators.
- Backup and restore owner.
- Security or audit owner.
- Support escalation owner.
- Any temporary access that must be disabled after handover.
RBAC and Department Readiness
DeskDox access is controlled through roles, permissions, departments, and document or folder-level access rules. Before go-live, administrators should confirm that the first set of users can perform only the actions required for their responsibilities.
| Access area | Validation example |
|---|---|
| Upload and edit permissions | A normal document user can upload where expected and cannot modify restricted administration settings. |
| Approval permissions | Approvers can open assigned tasks and cannot approve tasks outside their assignment. |
| Department visibility | Department users see the correct folders, documents, and workflow queues. |
| Administrative permissions | System administrators can open required settings while non-admin users cannot. |
| Audit visibility | Audit or compliance users can view required history without receiving unnecessary write access. |
MFA and Password Policy
If MFA or stronger password rules are required by customer policy, enable and validate those controls before broad user onboarding. Confirm whether MFA is optional, administrator-only, or required for all users according to the customer's security policy.
Password reset and invitation flows depend on correct public URL and SMTP configuration. Validate email links after the production FQDN is configured so users receive links that open the intended DeskDox environment.
License Activation Planning
DeskDox licensing may use online or offline activation depending on the deployment package and customer environment. The deployment team should confirm:
- Who owns license activation.
- Whether internet access is available from the deployed environment.
- Whether offline challenge/response activation is required.
- Whether the license state must be preserved in backup and restore planning.
- Which licensed features must be validated before go-live.
Identity and Access Go-Live Checks
Before go-live:
- Named administrators can sign in.
- Temporary implementation access is removed or has a documented removal date.
- Required roles and departments are configured.
- Representative users have passed permission checks.
- MFA and password policy match the approved customer baseline.
- SMTP-dependent account and notification flows have been tested.
- License activation state is valid and feature access has been confirmed.