Features

Every feature, organised by job to be done

ip·Solis is opinionated. Here is the full surface area, grouped by the team that uses it most.

Self-service

  • Employee portalA dedicated "My IT" view shows every active asset the employee holds, with extend, modify, return, and cancel actions available in one place. The request catalogue is filtered by entitlement, so each user only sees the assets they are eligible for. Cost projections, data-classification badges, and per-asset help text are shown at request time — no tickets, no admin involvement.
  • Entitlement-aware catalogueThe catalogue is dynamically filtered to assets the requester is entitled to — based on AD group membership, department, or explicit grants configured on each asset definition. The request form adapts to the asset's attribute schema and renders PII, PHI, and PCI warnings in-line so requesters understand what data they are handling before they submit.
  • One-click manager approvalApproval requests arrive by email with a signed tokenized link that grants or declines without requiring a portal login. Managers can also act from a dedicated Microsoft Teams channel via Adaptive Card. Delegation windows let managers pre-configure deputies for planned absences, and conditional multi-approver workflows with N-of-M quorum are available for regulated asset types.
  • Order timelineEvery order moves through a defined state machine — Pending Approval, Scheduled, Processing, Provisioning, Provisioned — visible in a live status view the employee can check at any time. Per-step runbook output, timing, and error messages are accessible in the order detail so operators can diagnose failures without querying the database.
  • Cancel and revokeEmployees can cancel their own orders up until the runbook starts executing. Once provisioned, the Return action triggers the configured deprovision runbook, which removes access and — depending on the policy — returns the asset to the pool or queues it for reinstall. Every action is recorded in the audit log with full attribution.

Lifecycle & Asset Pool

  • Asset definitionsA single asset definition captures the assignment model, provisioning and deprovision runbooks, entitlement rules, attributes, cost, and data classification in one place. Every order placed for that type inherits these settings automatically, so changes take effect immediately without touching existing records.
  • Pooled assignmentPool-model assets draw from a shared capacity bucket — when a user requests access, an available instance is allocated; when they return it, it goes back to the pool and is optionally reinstalled via a wipe runbook before the next user. Real-time dashboard tiles show Free, In Use, Reinstall, and Failed counts with warnings at ≥80% and critical alerts at ≥95% capacity fill.
  • Personal assignmentPersonal-model assets create or reuse a dedicated instance per user — the right fit for individually assigned workstations, named SaaS licenses, or any resource where a fixed identity-to-asset binding is required. Per-type capacity limits and expiry dates are enforced, and renewal requests go through the same approval pipeline as new requests.
  • Recycle workflowsWhen an asset is returned or expires, the deprovision policy determines the outcome: access-only removal, clean return to the pool, or a full reinstall runbook that wipes the machine and marks it Free for the next user. Each policy is configured independently per asset type, so a shared lab desktop and a named SaaS seat follow different paths without custom scripting.
  • Leaver-event deprovisionA SCIM 2.0 deactivation or a direct HR webhook automatically revokes every active order the departing user holds and dispatches the appropriate deprovision runbook for each asset. Pending approvals where the leaver was the designated approver are superseded so queues do not stall. The flow is idempotent — re-firing the same event for the same user is always safe.

Automation & Runbooks

  • Native PowerShell 7 workerip·Solis runs a native pwsh 7 worker on Linux, so existing AD, SCCM, XenServer, and VMware scripts execute unchanged without a Windows host or wrapper layer. PSGallery modules can be installed at build time or uploaded manually, each flagged for Linux compatibility so the worker skips Windows-only modules automatically.
  • Chained runbook stepsRunbooks are composed of ordered steps, each calling a stored PowerShell module with configurable static parameters and template variables such as {{order.username}} and {{asset.name}}. Every step records its input arguments, structured JSON output, duration in milliseconds, and any error message in the order log, giving operators a full execution trace.
  • Critical-step semanticsAny step failure immediately halts the runbook and moves the order to Failed, surfacing the step error message in the admin UI without further processing. This prevents partial-provisioning states — where, for example, an AD group was added but a SCCM task sequence never started — from going unnoticed.
  • Cron schedulesStandalone runbooks can be scheduled with standard cron expressions (minute, hour, day-of-month, month, day-of-week) with configurable timezone support. Each scheduled run is recorded in a run history with per-step output, and the scheduler dispatches ready jobs every minute with overlap protection per asset.
  • Overlap protectionA per-asset execution lock ensures that concurrent provision and deprovision jobs for the same asset are never dispatched simultaneously. This prevents race conditions in multi-step runbooks that modify AD group membership, VM power state, or SCCM collections — making runbooks safe to schedule aggressively without defensive scripting.

Compliance & Audit

  • Access certification campaignsCampaigns define a scope — by asset type, cost center, department, or individual users — and materialise one review row per active order for each manager in scope. Managers receive signed-token review URLs by email and can confirm or revoke access without a portal login. Overdue reviews can be auto-revoked on a configurable deadline, and evidence exports are available per campaign for ISO 27001, SOX, and PCI DSS auditors.
  • Append-only audit logThe audit log is protected by PostgreSQL before-triggers that block all DELETE, UPDATE, and TRUNCATE statements at the database level — not just the application layer. Every row records the entity, action, a full before/after JSON diff, and a precise attribution string that distinguishes portal users, admin sessions, named API tokens, one-click approval links, and automated system tasks. Secrets are never included in diffs.
  • SCIM 2.0 endpointThe /scim/v2/ endpoint accepts provisioning and deactivation events from Okta, SailPoint, Ping, Entra ID, and any SCIM-compliant identity provider. Provisioning calls are acknowledged as no-ops (ip·Solis does not maintain a user directory); a DELETE or PATCH with active=false immediately triggers the unified leaver flow across all active orders.
  • HR leaver webhookA purpose-built webhook at /hr/leaver accepts payloads from Workday, SAP SuccessFactors, Microsoft Graph Change Notifications, and custom systems via built-in payload adapters. Authentication supports either HMAC-SHA256 body signing or a scoped bearer token (hr:leaver scope), so each source system carries its own revocable credential.
  • Evidence exportAudit log entries can be filtered by entity type, actor, time window, and change kind, then exported to CSV. Certification campaign results include per-review decisions, timestamps, and reviewer attribution — the complete evidence trail required to demonstrate access governance to external auditors.

FinOps & Cost

  • Per-provider cost reportThe provider view aggregates projected monthly spend by the cost center assigned to each asset type, giving platform teams a real-time view of what each system they operate costs the organisation. Historical daily snapshots allow retrospective analysis without losing live order data.
  • Cost-center and department viewsThe consumer view aggregates by the AD attributes snapshotted from the requester at order-creation time — department, cost center, company, and employee ID. Because these are permanent snapshots on the order row, the report remains accurate even if the requester changes team or leaves the organisation after placing the order.
  • Threshold alertsPer cost-center spend ceilings trigger email notifications and Microsoft Teams Adaptive Cards when projected monthly spend crosses the configured limit. A quiet window (default 24 hours) prevents repeat alerts when spend hovers at the threshold, and editing a threshold immediately resets the alert clock so the next breach always notifies.
  • CSV exportThe full per-order cost breakdown — including requester HR identity, asset type, monthly cost, and cost center — can be exported to CSV at any time. The export covers all order origins (portal, API, ServiceNow webhook) so finance and chargeback workflows get a single coherent dataset.

Integrations

  • Active DirectoryThe PowerShell 7 worker speaks ADWS natively using NTLM signing or Kerberos authentication. Runbook steps can add or remove users from security groups, set attributes, and query the directory. The manager relationship is resolved live at order-creation time for approval routing — not stored — so reporting-line changes are reflected automatically.
  • SCCMSCCM integration covers device import, task sequence triggering via WinRM, and AdminService REST API calls authenticated with Kerberos. A built-in status probe polls task sequence completion asynchronously and advances the order state automatically, so the runbook does not block the Celery worker thread while SCCM deploys an OS image.
  • XenServer / VMwareVM lifecycle operations — clone, power on/off, snapshot, delete — are implemented as PowerShell modules (PowerCLI for vSphere, XenAPI for XenServer/XCP-ng) called from runbook steps. SSL bypass for self-signed certificates is pre-configured, and stdin injection handles interactive-prompt workarounds so lab and air-gapped environments work without script modifications.
  • SCIM 2.0 IdPsThe /scim/v2/ endpoint integrates with Okta, SailPoint, Ping Identity, Entra ID, and any RFC 7644-compliant identity provider. User create and update calls are acknowledged but no-op; deactivate calls — DELETE or PATCH active=false — trigger the unified leaver flow that revokes every active order and dispatches deprovision runbooks automatically.
  • Generic webhookThe ServiceNow inbound webhook accepts HMAC-SHA256-signed payloads and creates orders through the same approval and runbook pipeline as portal requests. Requester AD attributes are snapshotted at creation time, so ServiceNow-originated orders appear correctly in cost-center and department breakdowns alongside portal and API orders.

Security

  • Scoped API tokensNamed tokens (format: xpat_…) are shown only once at creation and stored as SHA-256 hashes. Each token carries one or more granular scopes — admin:read, orders:write, scim:write, hr:leaver, and others — and can be bound to a specific admin role. A mint guard prevents privilege escalation: a creator can only issue tokens at or below their own role level.
  • Admin RBACFive roles — superadmin, admin, approver, auditor, helpdesk — govern exactly what each admin account can see and change. Per-asset-type ACL grants further scope individual admins to a subset of asset definitions so operators only see what they manage. A separation-of-duties check prevents the admin who configured an asset type from approving access requests for it.
  • Secret handlingAll integration credentials — AD bind password, SMTP, vSphere, XenServer, SCCM, Teams webhook — are stored in the app_config table, never in environment variables or container images. Any secret-typed key can reference an external store (HashiCorp Vault, CyberArk CCP, Azure Key Vault, AWS Secrets Manager, or Conjur), resolved at read time with a 60-second TTL cache.
  • TLS everywhereAll external-facing endpoints enforce TLS at the reverse proxy; plain HTTP connections are rejected. SCIM, HR webhook, the portal, and the admin API all require TLS, and SMTP is configured TLS-only. Internal container-to-container traffic runs exclusively over the isolated Docker network.
Every feature, organised by job to be done — ip·Solis