Lifecycle & Asset Pool

ip·Solis manages the full lifecycle of IT assets — from initial assignment through expiry, extension, return, deprovisioning, and leaver revocation. This page covers the data model and configuration options that govern how assets move through their states.

---

Assignment Models

Every asset type is configured with one of three assignment models that determine how assets are allocated.

Capacity-Pooled

A shared pool of fungible assets. When a user requests one, ip·Solis picks an available asset from the pool, assigns it, and tracks the assignment for the lifetime of the order. On return, the asset goes back into the pool.

Typical use: virtual desktops, VPN accounts, shared servers.

Per-user quota (max_per_user) — optionally limits how many instances a single user can hold simultaneously. Counted across all non-terminal order states.

Dedicated-Shared

A fixed asset shared by multiple users simultaneously. No depletion — every order for this type points at the same shared resource. Deprovisioning removes the user's access but leaves the asset untouched.

Typical use: jump hosts, shared application servers, team file shares.

Assigned-Personal

A 1:1 asset-to-user relationship with no shared pool. Each order creates or manages a dedicated asset for that specific user.

Typical use: physical workstations, personally assigned licenses.

---

Asset Statuses

Status	Meaning
Free	Available in the pool, ready for assignment
reserved	Held by a scheduled order — not yet active, but unavailable to other requesters
busy	Actively assigned to a user
Reinstall	Queued for reinstall after return-to-pool-reinstall deprovision
Reinstalling	Reinstall runbook currently executing
Failed	Reinstall runbook failed — manual intervention required
maintenance	Taken offline by an operator

The admin dashboard shows tile counts for Free / In Use / Failed / Reinstall / Maintenance / Total, updated via live HTMX fragments. (The asset pool list labels the same state "Assigned" — both refer to the underlying busy status.)

---

Asset Type Configuration

Asset types are defined in Admin → Asset Definitions.

Key fields:

Field	Description
Category	Groups asset types in the portal catalog
Assignment model	Capacity-pooled, dedicated-shared, or assigned-personal
Automation strategy	Group Access, Runbook, or Composite — see Automation & Runbooks
Deprovision policy	What happens when an asset is returned or expired
Pool capacity	Maximum pool size; capacity warnings appear on the dashboard at ≥80% / ≥95% fill
Lifecycle renewable	Whether users can request extensions
Eligible requestors	AD group restriction — only members can see and request this type
Max per user	Per-user quota (pooled and personal models)
Active / inactive	Inactive types disappear from the portal but historical orders remain intact

---

Deprovision Policies

The deprovision policy controls what ip·Solis does when an order is returned, expired, or cancelled.

Policy	What happens
access_only	Removes user access (AD groups, etc.) but leaves the asset in its current state
return_to_pool	Removes access and marks the asset as Free in the pool
return_to_pool_reinstall	Removes access, marks as Reinstall, then runs the reinstall runbook before returning to Free
deallocate	Removes access and deallocates the underlying resource (e.g., powers off a VM)
delete	Removes access and deletes the underlying resource permanently
custom_runbook	Runs a fully custom deprovision runbook defined per asset type

---

Expiry and Renewal

Every provisioned order has an expiry date. A Celery Beat task (check-expiring-assets) runs hourly to:

1. Send reminder emails to users whose assets expire within the configured warning window
2. Automatically trigger deprovision for assets past their expiry date

Users can request an extension from the My IT portal page if the asset type has lifecycle_renewable enabled. Extensions are subject to the same approval rules as new orders.

---

Access Certification Campaigns

Certification campaigns let compliance teams periodically review which users have active access to specific asset types — a requirement for ISO 27001, SOX, and PCI audits.

Creating a Campaign

In Admin → Certifications, create a campaign with:

• Scope — filter by asset types, cost centers, departments, or specific requester emails
• Due date — when reviews must be completed
• Escalation contacts — who to notify if reviews are overdue
• Auto-revoke on overdue — opt-in: unreviewed access is automatically pulled after the due date

Review Flow

When a campaign is started, ip·Solis materialises one review row per (matching order, reviewer = the order's manager). Reviewers receive a kickoff email with a signed-token URL that opens a no-login review queue. From there they choose:

• Confirm — the user keeps access; the review is closed
• Revoke — ip·Solis immediately triggers the deprovision runbook for that order

Automated Reminders

A daily Beat task sends reminder emails at configurable offsets before the due date (default: 7 days and 1 day before), an overdue notification after the deadline, and a summary to escalation contacts. Auto-revoke, when enabled, fires for all unreviewed rows past the due date.

Portal Review Queue

Reviewers with Entra ID SSO can also access their review queue at /portal/certifications — no separate admin account required.

---

HR Leaver Flow

When a user leaves the organisation, ip·Solis automatically revokes all their active access. The leaver flow is triggered by one of two entry points:

• HR webhook at POST /hr/leaver — purpose-built for Workday, SAP SuccessFactors, Microsoft Graph, and custom HR systems
• SCIM 2.0 at /scim/v2/* — a leaver-focused subset of RFC 7644, compatible with Okta, SailPoint, and Ping deprovisioning connectors

Both paths run the same process_leaver() logic:

1. Every active order (pending, pending-approval, scheduled, processing, provisioning, provisioned, delivered) is set to REVOKING and its deprovision runbook is dispatched
2. Pending approvals where the leaver was the approver are superseded — so quorum logic doesn't stall
3. Pending certification reviews assigned to the leaver are superseded — so campaigns continue without manual reassignment

The flow is idempotent — re-firing for the same email is harmless; already-revoked orders are no longer in the active set.

Monitoring Leaver Events

Admin → Leaver Events shows recent events with status badges (received / processed / failed), per-event counts of what was revoked/superseded, and the triggered_by audit trail so you can trace each event to its source.

HR Webhook Setup

Authentication: either a scoped API token (scope hr:leaver, preferred) or an HMAC-SHA256 body signature using WEBHOOK_SECRET_TOKEN.

Supported payload shapes:

Vendor	Shape
ip·Solis native	{"email": "alice@example.com"}
Workday	{"workerId": "WD-…", "eventType": "terminated", "primaryEmail": "…"}
SAP SuccessFactors	{"PERSON": {"PERNR": "…", "email": "…"}}
Microsoft Graph	{"value": [{"resourceData": {"userPrincipalName": "…"}}]}

SCIM 2.0 Setup

Mint a token with scim:read + scim:write scopes from Admin → API Tokens and paste it into your IDP connector configuration. DELETE /scim/v2/Users/{id} and PATCH active=false both trigger the leaver flow.