User Access Request Workflow

How is this workflow audited for compliance and security reviews?

Every action taken within the workflow — including approvals, rejections, provisioning confirmations, and status changes — is recorded with a timestamp and the identity of the responsible user inside assess.one. This creates an immutable audit trail that can be reviewed at any time without reliance on email threads or external ticketing systems. Auditors and security teams can inspect individual records or export data to support internal reviews, ISO 27001 audits, SOC 2 assessments, or regulatory inspections.

Who has access to review, approve, or action requests in this workflow?

Access and permissions are configured directly within assess.one, allowing administrators to assign specific roles — such as requester, line manager, system owner, and IT provisioner — to the appropriate individuals or groups. Each role only sees and acts on the steps relevant to their function, enforcing least-privilege principles within the workflow itself. Role assignments can be updated at any time without developer involvement, ensuring the process remains aligned with organisational structure changes.

How does this workflow integrate with email and communication tools like Slack?

Email and Slack integrations are configured directly inside assess.one — no third-party development work or external middleware is required. Automated notifications are triggered at key points, including request receipt confirmation, approval decisions, provisioning completion, and issue resolution, keeping all stakeholders informed without manual intervention. Notification recipients, message content, and trigger conditions can all be customised within the platform.

How long does it take to implement this workflow?

The template can be published and live within minutes — there is no weeks-long implementation project or software installation required. Once published, your team can begin submitting and processing real access requests immediately. Customisation of steps, approval logic, roles, and notifications is completed directly within assess.one before or after go-live.

How can the workflow be customised to match our internal access control policies?

All workflow steps, approval routing logic, required fields, and notification rules are configurable directly within assess.one without writing any code. Organisations can add additional approval tiers, adjust business justification requirements, modify provisioning checklists, or introduce conditional routing based on resource sensitivity or requester department. Changes take effect immediately upon saving, allowing the workflow to evolve alongside policy updates.

What happens when a manager rejects an access request?

When a manager selects the rejection outcome at the Manager Approval step, the workflow routes to the Set Status to Rejected by Manager step, formally closing the request at that stage. The requester can be automatically notified of the rejection outcome via the platform's notification configuration, providing transparency without requiring manual communication. The rejection decision, including any comments entered by the manager, is preserved in the access request record for audit purposes.

How are access issues identified after provisioning handled?

Following the Provision Access step, the Verify Access step requires confirmation that the access has been correctly applied. If verification fails, the workflow routes to the Set Status to Access Issue step and opens an Investigate and Resolve Access Issue task for the IT team. Once resolved, the workflow progresses to Set Status to Completed After Fix and automatically notifies the requester, ensuring no request is silently abandoned and that every resolution is documented.

Can this workflow support separation of duties between manager and system owner approvals?

Yes — the workflow enforces a sequential dual-approval structure in which manager approval must be obtained before the request is routed to the system owner for their independent review. These two approval roles are assigned to different individuals or teams within assess.one, ensuring that no single person can both authorise a business need and grant technical access. This separation of duties is a core control requirement under frameworks such as ISO 27001 and SOC 2 Type II.

How does the workflow handle provisioning details for future reference?

The Save Provisioning Details to Record step captures the specifics of what access was granted, by whom, and when, directly within the access request record in assess.one. This means provisioning information is permanently associated with the original request and approval chain, providing a complete lifecycle record. This data is available for access reviews, recertification campaigns, and deprovisioning decisions without requiring manual documentation in separate systems.

Is this workflow suitable for managing access across multiple systems or business units?

The workflow is designed to be scalable across diverse systems and organisational units, with resource and permission specification captured at the request creation stage to contextualise each approval and provisioning action. Administrators can configure system-owner routing rules so that requests for different platforms are directed to the appropriate technical owners automatically. For large organisations managing access across many systems, multiple instances of the workflow can be run concurrently within assess.one without performance or governance degradation.