The workflow editor: build processes that steer themselves

"Can you get me a new laptop?" Anyone who knows requests like this also knows the back and forth: who is responsible, what has been done, who is waiting for whom? In Resourcecloud's workflow editor you turn a recurring request into an offering with fixed steps. Anyone requests it in a form, and the right teams get their step in the right order.

An offering in four building blocks

1. Name, description and tags. Requesters see these in the list.
2. Who may start it. You pick roles or open it to everyone. The list only shows an offering to people who may start it, and the server checks again on submit.
3. Input fields for the requester: text (optionally with a pattern, such as an IP address), number, date or selection list. All are required and checked on the server.
4. Steps. For each step you set the team, title, effort estimate and predecessor. Steps without a predecessor start immediately, the others when the step before them is done.

What happens then

Starting a request creates a main task with the requester's details and one task per step in that step's team. The teams work on them like any other task: take them from the pool, assign, comment, book time. When the last step is done, the main task closes. Starting is all or nothing: if a field is wrong, nothing is created.

Whoever made the request follows it under My service requests. The progress bar shows the share of estimated effort that is done, and for every step whether it's done, in progress or waiting.

Required entries per step

With step fields you force the person working on a step to enter something before they can complete it, such as a ticket or serial number. Without the value the step can't be closed, neither by button nor by API.

Let other systems take part

With triggers, another system reacts as soon as a step is done: a provisioning job starts, an account is created, a chat channel is notified. There are two kinds:

• Call before completing: the step only counts as done if the address answers with 200. Good when the next step depends on it.
• Send as webhook: signed, with retries when the other system is unavailable. Good when it only needs to be informed.

You can write fields of the offering into the address as variables. A trigger dashboard shows what fired and what failed. Together with n8n, the REST API and MCP, whole processes can be automated.

Good to know

Changing an offering doesn't change running requests: they keep the steps they were started with.