PROCESS AUTOMATER
Change processes without rebuilding the backend
The Process Automater puts business processes as configuration on top of an existing backend. Phases, conditions, required fields, validators and actions live in one place instead of being scattered across tool customizing. The data stays where it already lives. In production for a stage-gate model in a regulated enterprise environment; open to other backends and processes.
The process as YAML, not as customizing
Business processes have phases, transition conditions, required attributes and responsible people. In the Process Automater those building blocks live in configuration that the server loads at runtime. A new phase, an additional required attribute or a changed condition is a model change, not a click marathon in tool customizing. Variants, shared definitions and deviations are kept in the same artifact that later gets executed. Business, operations and development discuss the same process instead of three versions drifting apart.
Validators, actions, watchers
On every phase transition a configured chain runs: validators check required fields, permissions and consistency; actions write attributes, set labels, post comments, trigger webhooks or notify third-party systems. Watchers additionally react to changes on individual fields, also outside classic phase transitions. New rule and action types can be added without rebuilding existing processes. What used to be documented as a check requirement becomes an executable rule — traceable, repeatable and maintained in one place.
On the backend you already use
The Process Automater is a layer on top of your system of record — it keeps no copy of its own. Sources read business attributes, targets write back the computed result. Currently in production with Jira as the backend, technically open to others: Confluence, an ERP, a database, or a mix of several systems. Business attributes can be read from different sources, business rules defined on top, and results written back to different targets — a process can therefore span across backend boundaries. Main use case today: a stage-gate model for product initiatives in a regulated enterprise environment, where the central Jira instance is meant to stay intentionally thin. A dedicated wizard UI creates new items, OIDC/SSO is wired in, REST and webhook endpoints connect third-party systems. Starting on a different backend is not a green-field exercise — it happens through additional source and target types, not through a refactor of the core.
Simulate first, then commit
Destructive actions can be dry-run before they take effect. In dry-run mode the server computes the full phase transition including validators and targeting but does not write the result back to the backend. What would have happened is visible; what happens is suppressed. Permissions are checked at three points: process access, read access on the item, and configurable groups per condition. Every step produces an audit entry in the operation store, with dry-run runs explicitly flagged. A bulk step reports its outcome per item — successes and failures separately; one stumble does not abort the rest.
Usable from LLM clients, too
An MCP layer exposes the domain operations directly to LLM-based clients — Claude Desktop, internal agents, custom integrations. Instead of wrapping the REST API, clients call dedicated tools: getFeature returns the current state, including phase, attributes and condition status; bulkConfirm sets confirmation markers for a list of items. Authentication and permissions come from the same source as for the REST API; a tool call is checked the same way as a regular web request. Write-side tools accept a dry-run flag, so an agent can preview the planned outcome to the user in real tool semantics before triggering it.