Think of Paola ordering a coffee. Her order is New. When she pays, it becomes Paid and a receipt is printed. When the barista prepares it, it becomes Ready and her name is called. Each line reads: in this state, this event moves the order to that state and does these things.
An IremboHub workflow is exactly that. Each transition has a start state, an event, an end state, and actions that run on the way (generate a bill, send an SMS, assign an office, generate a certificate).
▶ Video walkthrough in the Rise course: Watch how to create a workflow using the visual editor.
| Card | Answer |
|---|---|
| State | Where the application is: PAYMENT_PENDING, PENDING_OFFICER_PROCESSING, APPROVED. You name the states; the first is always NEW. |
| Event | What happens: APPLY, PAY, APPROVE. Events come from a fixed list. |
| Transition | Start state + event → end state, with actions. The officer sees one button per transition they are allowed to fire. |
| Breaking action | Must succeed. If it fails, the event fails and the application stays in its start state (bill generation, office assignment, certificate). |
| Non-breaking action | Best effort. A failure is logged and the transition still completes (notifications). |
| endStateTwo | An alternative end state, used when its conditions are true, or on APPLY when the application is free. |
| System event | Fired by the platform, not a person: PAY, EXPIRE_PAYMENT, ASSIGN_OFFICE. Mark it "system authorised". |
| nextEvent | An event fired automatically as soon as a state is reached, e.g. PENDING_ASSIGN_OFFICE → ASSIGN_OFFICE. |
Events you can use (a fixed list: you cannot invent an event)
| Event | Who fires it | Typical use |
|---|---|---|
APPLY |
Applicant (ROLE_CITIZEN, ROLE_AGENT...) | Creates the application from NEW |
PAY |
System (IremboPay) | The bill was paid |
EXPIRE_PAYMENT |
System | The bill expired |
ASSIGN_OFFICE |
System | Send the application to an office |
APPROVE, REJECT |
Officer | Decide |
APPROVE_WITH_FORM |
Officer | Approve with the officer form data (or a partner document) |
REQUEST_FOR_ACTION |
Officer | Ask the applicant to correct something |
SUBMIT_RFA |
Applicant | Send the corrections back |
ESCALATE |
Officer | Move to a higher office level |
SET_APPOINTMENT |
Officer / applicant | Appointment services |
TRANSITION |
Officer or system | A generic step with your own name (for example "Verify documents") |
CANCEL |
Applicant / system | Cancel the application |
INITIATE_PUSH, PUSH, PUSH_CALLBACK |
System / partner | Integrated services (Section C) |
Authorisation on each transition
| Who may fire it | Set with | Example |
|---|---|---|
| Roles | authorisedRoles | ROLE_CITIZEN, ROLE_AGENT on APPLY; ROLE_OFFICER on APPROVE |
| Specific users | authorisedUsers | Only named officers (rare) |
| The system | systemAuthorised | PAY, EXPIRE_PAYMENT, ASSIGN_OFFICE |
Gotcha · TRANSITION is an event, not an action
You will see
TRANSITIONin the event list. It is a generic event with a custom display name; it does not "do" anything by itself. The actions are the list in lesson B7.
| Item | Matches |
|---|---|
| APPLY | Applicant submits the form |
| PAY | IremboPay confirms payment |
| ASSIGN_OFFICE | System sends the application to an office |
| APPROVE | Officer accepts the application |
A notification action fails because the SMS gateway is down. What happens to the transition?
D. Non-breaking actions never block a transition. Put an action as breaking only when the next state makes no sense without it (a bill before PAYMENT_PENDING, an office before PENDING_OFFICER_PROCESSING).
← A7 · Pricing basics: free, fixed and where the money goes · A9 · Build the demo workflow →