IT & Security package

Access request and provisioning

People request application access from a form; risk-based approvals route it, the grant is provisioned automatically and time-boxed access is revoked on expiry.

Starts from a formIntermediate~15 min setupv1.0.0
Download .utpkg 19 KBHow to install

About this package

What it does

Access request and provisioning takes an application access request from a form through to a live grant. The requester picks the application, the role or entitlement, how long the access is needed (30 days, 90 days or permanent), who it is for and why.

The workflow looks the person up in the identity platform, reads the application from the Application catalogue (owner, risk level, privileged flag, provisioning group) and evaluates the Access approval path decision table. Every request goes to the line manager; medium-risk applications also need the application owner, and high-risk or privileged roles add a security review. Approvals run in sequence and any rejection stops the request and emails the requester.

Once approved, the grant is created through the identity API and the requester is emailed. For time-boxed access a sub-workflow waits 30 or 90 days and revokes the grant, so temporary access never outlives its approval. Adapt the catalogue, the approval rules and the identity API paths to your platform.

Starts from a form

Starts from a form: the requester fills in the application, role, duration and justification (Run dialog, or your service portal posting to the start API).

Someone fills in a form to start it: the workflow inputs are the start form (Run dialog in the app, or your own portal posting to the API), and people complete User Task forms along the way.

The flow

Step by step

  1. 1

    Request access

    The start form collects the application, role, duration, justification and the employee id of the person who needs it.

  2. 2

    Look up user and application

    Get user returns the person and department; the Application catalogue gives the risk level, privileged flag and provisioning group.

  3. 3

    Decide the approval path

    The Access approval path decision table chooses manager only, manager and owner, or manager, owner and security, and sets the request SLA.

  4. 4

    Approve in sequence

    The manager, then the application owner and security reviewer where required, approve or reject. Any rejection emails the requester and closes the request.

  5. 5

    Provision the grant

    The identity API adds the user to the provisioning group and returns a grant id; the requester is emailed.

  6. 6

    Revoke on expiry

    For 30- or 90-day access, the Revoke access on expiry sub-workflow waits out the period, revokes the grant and tells the requester.

Access request — Someone requests access to an application; the catalogue and approval path decide which approvals it needs, then the grant is provisioned in the identity platform and removed automatically when time-boxed access ends. The same canvas you get in the designer after installing.

Sub-workflow: Revoke access on expiry

Waits for the length of a time-boxed grant, then revokes it in the identity platform and tells the requester. Started by the Access request workflow.

Forms

The start form and the task forms

The workflow inputs are the start form: the Run dialog renders them, and your own portal can post the same fields. User Tasks show their fields and outcome buttons to the assignee.

Start form

Access request

Filled in by whoever starts the process

Your name * requester_name · textYour name
Your email * requester_email · emailname@company.comWhere to send the outcome
Requested for (employee id) * employee_id · textEmployee id of the person who needs the access (yourself or a team member), e.g. E-2040
Application * application · select
Finance ERPCRMHR systemData warehouseSource controlCloud console (admin)+1
Application from the Application catalogue
Role / entitlement * role · textRole or entitlement inside the application, e.g. "Accounts payable clerk"
Business justification * justification · textWhy the access is needed and what it will be used for
Duration * duration · select
30 days90 dayspermanent
How long the access is needed; time-boxed access is removed automatically
Manager (user id) manager_user_id · textOptional: user id of the line manager approver (overrides the default chosen on install)
Application owner (user id) app_owner_user_id · textOptional: user id of the application owner approver
Security reviewer (user id) security_user_id · textOptional: user id of the security reviewer

User Task

Manager approval

Approve access: {{user_name}} → {{application}} ({{role}})

Role is right for the job role_confirmed · boolean
Comment comment · text
ApproveReject

User Task

Application owner approval

Owner approval: {{application}} {{role}} for {{user_name}}

Provisioning group * provisioning_group · textPrefilled: {{app.provisioning_group}}
Segregation-of-duties checked sod_checked · boolean
Comment comment · text
ApproveReject

User Task

Security approval

Security review: {{application}} {{role}} for {{user_name}}

MFA / PAM enforced for this role mfa_enforced · boolean
Security notes comment · text
ApproveReject

From your code

Start a run over the API

Every workflow can be started over REST, MCP or the CLI, whatever its trigger, with the sample input below. Runs start straight away on the published version; replace <workflow id> with the id the install created.

REST

shell
curl -X POST "$USERTASKS_URL/api/v1/workflows/start" \
  -H "Authorization: Bearer $USERTASKS_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"workflow_id":"<workflow id>","variables":{"requester_name":"Morgan Ellis","requester_email":"morgan.ellis@example.com","employee_id":"E-2040","application":"Finance ERP","role":"Accounts payable clerk","justification":"Covering supplier invoice processing during the quarter-end close","duration":"90 days"}}'

CLI

shell
usertasks workflows inputs <workflow id>          # the start form: keys, types, required
usertasks workflows run <workflow id> --input requester_name="Morgan Ellis" --input requester_email=morgan.ellis@example.com --input employee_id=E-2040 --input application="Finance ERP" … --wait

Inbound webhook

shell
usertasks webhooks create <workflow id>          # prints the hook slug and secret once
curl -X POST "$USERTASKS_URL/api/webhooks/inbound?hook=<slug>" \
  -H "Authorization: Bearer <webhook secret>" -H "Content-Type: application/json" \
  -d '{"requester_name":"Morgan Ellis","requester_email":"morgan.ellis@example.com","employee_id":"E-2040","application":"Finance ERP","role":"Accounts payable clerk","justification":"Covering supplier invoice processing during the quarter-end close","duration":"90 days"}'

What's included

11 assets, ready to adapt

TypeNameDetails
Email templateAccess expiredSent to the requester when time-boxed access is removed at the end of its period.
Email templateAccess grantedSent to the requester when the access has been provisioned.
Email templateAccess request declinedSent to the requester when an approver rejects the request.
Data tableApplication catalogueApplications people can request, with the owner, risk level, whether roles are privileged and the directory group that grants access. Edit the rows to match your estate.
IntegrationIdentity platform
API referenceCreate access grantPOST /access-grants — Add the user to the provisioning group for the application and role. Returns the grant id used to revoke it later.
API referenceGet userGET /users/{{employee_id}} — Directory record for the person who will receive the access: name, email, department and line manager.
API referenceRevoke access grantPOST /access-grants/{{grant_id}}/revoke — Remove a time-boxed grant when it expires.
Decision tableAccess approval path5 rules — Which approvals an access request needs, from the application risk, whether the role is privileged and how long access is requested for. First matching rule wins.
WorkflowAccess request25 steps — Someone requests access to an application; the catalogue and approval path decide which approvals it needs, then the grant is provisioned in the identity platform and removed automatically when time-boxed access ends.
WorkflowRevoke access on expiry9 steps — Waits for the length of a time-boxed grant, then revokes it in the identity platform and tells the requester. Started by the Access request workflow.

Application catalogue · 7 sample rows

ApplicationApplication ownerRisk levelPrivilegedProvisioning groupNotes

Requirements

What you connect it to

Credentials never travel in a package. The install wizard asks for what your environment must provide, or installs it incomplete until you finish setup.

Needs

  • REST API — A REST API integration: set its base URL and credentials on install.
  • Assignees — People in your workspace to receive the User Tasks (picked on install).
  • Email — Email delivery configured for the instance (EMAIL_PROVIDER), used for notifications.

After installing

  1. Identity platform integration: set the base URL of your identity / IGA API and an API token. The references expect GET /users/{id}, POST /access-grants and POST /access-grants/{id}/revoke; adjust paths and response models in Integrations.
  2. Assignees: pick the default line manager, application owner and security reviewer. Runs can override them with manager_user_id, app_owner_user_id and security_user_id.
  3. Edit the Application catalogue rows: your applications, owners, risk levels, privileged flags and the directory groups that grant access. Keep the application names in sync with the start form options.
  4. Review the Access approval path rules against your access control policy (which risk levels need owner or security sign-off).
  5. Email: configure EMAIL_PROVIDER on the instance so the granted, declined and expired emails are delivered (the steps continue on error).

Asked for on install

  • Integration “Identity platform”Required

    • Tokenconfig.auth_config.token
    • Base urlconfig.base_urldefault https://identity.example.com/api· optional

  • Workflow “Access request” assigneesRequired

    • User for step “Manager approval”nodes.8.config.assignee_id
    • User for step “Application owner approval”nodes.10.config.assignee_id
    • User for step “Security approval”nodes.13.config.assignee_id

Install

Install it in your workspace

Works on UserTasks cloud and on any self-hosted instance. Installing creates the assets above; nothing runs until you complete setup and start it.

In the app

  1. Download access-request-provisioning-1.0.0.utpkg.
  2. Open Automations → Packages and drag the file onto the page (or choose Import package). Browse gallery there lists every gallery package without downloading by hand.
  3. Pick the file. The wizard verifies the checksum, every file hash and the signature, and shows the readme.
  4. Review the changes (what is created) and the data rows.
  5. Fill in the requirements, or tick Keep incomplete and finish later with Complete setup.
  6. Done: the workflow is published and active once setup is complete.

With the CLI

shell
curl -fLO https://usertasks.com/gallery/access-request-provisioning-1.0.0.utpkg
usertasks packages inspect access-request-provisioning-1.0.0.utpkg       # offline: checksum, hashes, signature
usertasks packages install access-request-provisioning-1.0.0.utpkg --dry-run
usertasks packages install access-request-provisioning-1.0.0.utpkg       # prompts for each requirement
usertasks packages install access-request-provisioning-1.0.0.utpkg --keep-incomplete --yes   # in CI; finish with:
usertasks packages complete access-request-provisioning -f values.yaml

Verify the download

File SHA-256
175767b0a712007dfc44458ba78c079071c4f3ec7af449124c49fe14ed323186
Package checksum (what is signed)
sha256:392d656ec9af3d2562e67f66f1bc363744a160025799c8e020e809dd5a0ae4bc
Signer
Unsigned preview build — compare the SHA-256 above

shasum -a 256 access-request-provisioning-1.0.0.utpkg should print the file SHA-256. How gallery packages are signed.

Versions

Version 1.0.0

  1. v1.0.02026-10-26First release.

Installing a newer version upgrades in place: local credentials and requirement values are kept, and changes you made are flagged first. How packages work

More packages

Related

Browse the whole gallery