SolutionsConfigurable workflows

Draw how the work should go. Requests then actually go that way.

The shape of a process in continON is data: states, transitions, who acts at each one, what a step requires, and what every move fires. A submitted request becomes a live instance of that definition — so changing the definition changes what the next request does, without rebuilding the applications around it.

Structure
States and the transitions between them
Responsibility
An actor rule on every state
Information
A versioned form bound to the state
Control
Time limit, escalation target, verification
Consequence
Activities that fire on each transition
History
Every revision retained and traceable

Stored as metadata and interpreted at run time. A change is published, not deployed.

Two things can be true of one request at the same time.

  1. SubmittedThe initiator, on the bound form
  2. CheckedThe initiator’s supervisor · time limit
  3. Technical reviewA named group of positionsCost reviewThe head of the unit
  4. VerificationMust pass before the process may continue
  5. ApprovedThe transition fires the activities
  6. RecordedTrail kept, with the version it ran under

Technical review and cost review are both active on the same request. The engine holds more than one current state, checks that a target state is reachable through the transitions you drew before it moves, and only continues past verification when that step has passed.

What you decide once, and what a running request then experiences.

Who acts

A state names a rule, not a person: the initiator, the initiator’s supervisor, the current user’s supervisor, the head of the unit, someone chosen while the request is being raised, or a named group of positions. The rule is resolved against the org chart as it stands on the day the request runs, so a promotion or a transfer changes the route without anyone editing it.

What has to be filled in

A versioned form binds to the state and opens when work arrives there; submitting it advances the instance and carries the captured data with it. Its selects, defaults and lookups resolve from saved queries, so what people choose from is live data rather than a list typed into a screen.

What has to pass

A state can carry a time limit with an escalation target for steps that go overdue, and can be marked to require verification against your documented standards before the process may continue. Rejection paths are transitions like any other, so a refusal is a route on the definition rather than an exception outside it.

What the move does

Transitions are where a definition stops being a drawing. A move can notify and email, add or remove stakeholders on a request that is already running, execute a defined procedure, generate tasks for whoever has to act next, or merge the request’s own data into a template and file the finished PDF into the governed document store.

What survives it

Every saved revision of a definition is retained, so which version a given request ran under stays answerable long after the definition has moved on. Reports and dashboards read the same saved queries the forms did, granted to positions and partners rather than to individuals.

Where configuration stops.

Most change here is configuration: stages, fields, rules, layouts, grants. Past that, advanced users extend with SQL and JavaScript, and the table designer generates real database schema inside your own namespace. That is why continON describes the Builders as configuration you can extend — not as a way of getting rid of code.

Bring a process you argue about.

A guided walkthrough on a sanitized demo tenant: one definition drawn, a request submitted against it, two reviews running in parallel, and the document the approving transition produces.