How do I set up self-service provisioning in an internal portal?

To set up self-service provisioning in an internal portal, design it as a controlled workflow that lets users request and receive access/resources with minimal manual work, while keeping approvals, security, and auditability in place.

1) Define what can be provisioned

Start by listing the items users are allowed to request, such as:

• Applications / software access
• Cloud resources
• Test environments
• Accounts / groups / roles
• Devices or licenses

For each item, define:

• Who is eligible
• Required approvals
• Default duration / expiry
• Cost center or billing code
• Provisioning target system

2) Build the request flow

A typical flow is:

1. User signs into the portal
2. Selects a service from a catalog
3. Fills out a request form
4. Portal validates eligibility and policy
5. Approvals are routed if needed
6. Provisioning is executed automatically
7. User gets status updates and completion notice

Keep the forms simple and context-aware. Only ask for fields needed for that service.

3) Integrate with identity and access management

Connect the portal to your IAM/SSO system:

• SSO for authentication
• Role/group lookup for eligibility
• Automatic account/group assignment
• Just-in-time or time-bound access if possible

Common integrations:

• Azure AD / Entra ID
• Okta
• Google Workspace
• LDAP/Active Directory
• SCIM-enabled apps

4) Use workflow and automation

Use a workflow engine or orchestration layer to handle:

• Approval routing
• Policy checks
• Provisioning tasks
• Retry/error handling
• Notifications

Automation tools might include:

• ServiceNow workflows
• Power Automate / Logic Apps
• Camunda / Temporal
• Custom backend jobs
• Terraform / Ansible for infra provisioning

5) Add policy controls

To avoid “anyone can get anything,” enforce rules such as:

• Department-based eligibility
• Manager approval
• Security approval for privileged access
• Quotas or rate limits
• Expiration and auto-revocation
• Separation of duties

6) Provide status and transparency

Users should be able to see:

• Submitted requests
• Pending approvals
• Provisioning progress
• Final outcome
• When access expires

This reduces helpdesk tickets.

7) Log everything

Capture audit logs for:

• Who requested what
• Approvals and timestamps
• What was provisioned
• Who executed it
• Any failures or overrides

This is critical for compliance and incident review.

8) Handle exceptions

Not everything can be fully automated. Include:

• Manual review fallback
• Error notifications
• Reconciliation jobs to verify actual state
• A way to cancel or roll back requests

9) Secure the portal

Make sure the portal has:

• Strong authentication
• Role-based access control
• CSRF/XSS protections
• Input validation
• Secrets management
• Least-privilege service accounts
• Audit logging

10) Start with a pilot

Begin with one or two low-risk services:

• Software access
• Non-production environments
• Standard group memberships

Measure:

• Time to fulfill
• Approval turnaround
• Error rate
• Helpdesk reduction

Then expand based on feedback.

Suggested architecture

A simple implementation looks like:

• Frontend portal: request catalog and status page
• Auth layer: SSO integration
• Workflow service: approvals and orchestration
• Provisioning workers: API calls to target systems
• Database: request records and audit trail
• Notification service: email/Slack/Teams updates

If you want, I can also help you with:

1. a reference architecture diagram,
2. a sample database schema, or
3. a step-by-step implementation plan for tools like ServiceNow, Okta, or Azure AD.