The engine that turns a diagram into something an auditor can verify.
A modelled process and an executed process are different objects. One is a picture of intent; the other leaves a record of who did what, when, under which rule and with what evidence. Workflow is the module where the first becomes the second.
One engine, every record type.
Incidents, requests, problems, changes, releases and any record type you define run on the same workflow engine. That is not an implementation detail. It is why a survey defined once works across all of them, why an indicator can combine data from several practices without a mapping layer, and why an agent sees mixed work types in a single console instead of switching between isolated modules.
It is also why the engine carries processes that have nothing to do with IT. A tax audit, a medical claim review, a citizen request and a strategic plan have the same shape as a change request: forms, routing, approvals, deadlines, evidence, and an outcome someone is accountable for.
What it does
Execution, with the controls a regulated process needs
Every item below is configuration against the live record, not a development request.
Conditional routing →
Branch on any record data: service, component, location, risk score, requester attributes, approval outcome or the result of a previous task.
Sequential and parallel work →
Tasks run in sequence or in parallel, and a child task can carry assignment rules that differ from its parent — the coordinating team keeps the case while identity, endpoint, licensing, procurement and security each own their own step.
Cases whose route is not predefined →
Adaptive case management: tasks, participants and related data are added while the case runs — child and sibling activities from the viewer, a case team whose collaborators see and update it, cases merged — with the same traceability as a modelled route.
Approvals with real authority rules →
One approver, several in sequence or in parallel, approval groups, and N-of-M completion rules. Approvers resolve dynamically from the record: the requester’s manager, the application owner, the location owner, the security reviewer. Rejection either closes the record with a rejected classification or returns it to an earlier step with the comments attached.
Deadlines that respect the calendar →
Targets run as live timers against working calendars, holidays, service windows and group schedules — night and 24-hour shifts and each group’s break schedule included — with the site’s travel time added to the deadline and configurable exceptions for excluded periods and business cycles. Priority comes from an impact × urgency matrix. Escalation steps fire by the percentage of the service time consumed, before the deadline and after it.
Conditional data rules →
Each table or field of the case data takes its own rules — required only if, visible only if — over other case data, its state, priority or type. The form applies them live, and the server enforces them on save and on close, so a form asks only for what applies without losing a single control.
Projects on the same engine →
Projects start from a template and are planned and tracked in an editable Gantt: dependencies, the critical path, the projected finish date from the duration predictor, over-allocation by technician and the working calendar. Every project activity is a case on the same engine as tickets, with its owner, cost and deadline.
Runtime conditions that block progression →
A workflow can inject an additional review when live data crosses a threshold — insufficient lead time, a blackout collision, a risk score above a limit — and hold the record until the condition is satisfied. The injected task is part of the governed instance, not an informal note.
Deviation detection
A missed start, a record running past its planned end, an overdue approval, an execution overrun or an activated rollback can each raise an auditable flag, a notification, an escalation or a task, and can feed the final outcome assessment.
Absences, substitutes and transfers →
Absences are recorded in advance as unavailability windows with their reason and replacement, and while one is in force automatic assignment and appointment scheduling route to the replacement. When someone leaves, their open cases move to another person in one step, and a temporary or permanent substitute inherits their profile, groups, zones and expertise.
Overload, seen in time →
The load of each person and group across open work is flagged before it becomes breached deadlines — and a scheduled report can itself open the activities that act on what it finds, or notify another system.
Writes to the other repositories →
A workflow step can create or update assets, configuration items, licence consumption and service relationships. The change stays traceable from the process that caused it and from the record that received it — and any case event can also run an integration or a call to another system.
Append-only history →
Every record keeps who changed what and when, with the old and the new value. History is written by the engine and is not editable from the application; it can be searched, filtered, reported and exported.
Governance
What the engine does on its own, and what it will not do without you
Automation that cannot be audited is a liability in a regulated organisation. At each control point both paths exist, and the record says which one was taken, by whom or by which process, and when.
| Control point | Manual, and systematic |
|---|---|
| Assignment | A user assigns to a group or a person, and every reassignment is audited — or rules decide from category, service, component, requester, location, calendar and workload |
| Approval | A designated approver decides from the console, the responsive view or email — or authorisation is systematic, but only where a model explicitly defines that scenario |
| Escalation | A user escalates and states why — or time-based rules notify, escalate or reassign an overdue step |
| Closure | An authorised role closes and classifies the outcome — or closure follows the configured conditions: required tasks completed, validation successful, mandatory evidence attached |
| Related records | An agent launches a problem or a change from the case — or a density threshold opens the parent record and attaches the cases that triggered it |
Precision
The distinctions this module preserves
Three places where conflating two ideas produces a governance problem that only surfaces during an audit.
On the roadmap
What arrives next, and when
Each item is available for a demonstration or a proof of concept from the month shown.
Computer-use agents invoked from the process
A process activity hands a task in an application without an API to an external computer-use agent, with the same permissions, limits and log as any executor.
The proof
Twelve processes ran on this engine while an auditor watched
Change, incident, problem and request management are four of the twelve ITSM processes Pink Elephant certified in Dexon BPM. They are not four products: they are four configurations of this engine, differing in their templates, their routing and their authority rules. It is the most economical evidence we have that “executable” is meant literally.
See the twelve certified processes →The other capabilities of Dexon BPM
ETL & integration
REST API, scheduled and event-driven exchange with databases, files and web services, plus directory, email and discovery — with the authoritative source of every attribute on record.
Documents
Version trees, permissions, search by content, signature with time stamp — with document requirements enforced as gates the workflow will not pass without.
BI & KPIs
Scorecards under strategic objectives, targets by period, drill-down from the aggregate to the source record, and projection that never overwrites a measurement.
IT asset management
Inventory through the Dexon Agent, a CMDB that maintains itself, SNMP network discovery, licensing measured on real usage, and remote control recorded on the case.
Bring the process nobody wants to model
The one with the exception that breaks every tool: the approval that depends on the amount, the deadline that stops on public holidays, the step that only applies in one region. We model it live.