Modelling the process

The process is the path a case follows from submission to completion. You model it on the Service process tab with the process designer: a sequence of steps, each performed by a role or run automatically by the system.

The step library

Each step type has a task and the roles that may perform it. Steps fall into three kinds.

Applicant steps

Step	What happens
Fill e-Service Form	The applicant completes and sends the form
Make Payment	The applicant is asked to pay the configured fee through ZamPay

Officer steps

Step	Roles	What happens
Review Application	Case Officer, Supervisor	An officer reviews the application and its documents
Inspect Site	Case Officer, Supervisor	A visit with a checklist; the case cannot move on until findings are recorded
Approve	Case Officer, Supervisor, Executive	Approval at this level
Executive Decision	Executive	The final decision
Generate Invoice / Fees	Case Officer, Supervisor	An officer prepares the fee or invoice
Verify Payment	Case Officer, Supervisor	An officer confirms payment was received
Appointment with the Applicant	Case Officer, Supervisor	Biometrics, interview; the office records whether the applicant came
Hand Over Document	Case Officer, Supervisor	The holder collects the stamped document, or it is posted
Parallel approval	Several roles	Several approvers at once; complete when all, the first, or a set number approve
Hearing	Case Officer, Supervisor, Executive	Invitation letters, attendance and an outcome that decides what happens next
Instalments to another party	Case Officer, Supervisor	One party pays another in instalments, with proof of each

Automated steps (drawn dashed)

Step	What happens
Notify Client	Sends an SMS and/or e-mail to the applicant
Generate Output Document	Issues a document from the service's output templates
Decide route	Sends the case down one of several paths by conditions on the answers, the fee or the case. A default path is required
Wait / notice period	Holds the case for working or calendar days (an objection period), then moves on by itself

When a ministry module is switched on, it may add step types of its own (for example signing a lease). They appear in the palette only while the module is on, so a ministry without the module never sees them.

Configuring a step

Click a step to set its options:

• After this step, continue at: the next step, if not simply the one below.
• Who gets the case at this step: rows with a condition and an officer or an office pool, and a default when no

  row matches. For example, applications from one province go to that province's office.

• What officers may do at this step: optionally limit the actions allowed, the fields officers can see or change,

  and which documents are locked once the step is done.

• Performed by another ministry: the ministry, role and number of days of access, when a step belongs to a

  different MDA (for example an environmental clearance inside a land application).

• Where the case goes for this step: the hub office, back to the case's own office, or a named office.

A Decide route step has branches, each with a name, a condition and a target step, plus the default path. A Wait step has a purpose, a length, a unit (working or calendar days), a start and what happens at the end; it can collect representations from third parties, each of which must be considered before the decision.

Roles and separation of duties

Name the role that genuinely does each step, and keep duties apart:

• the person who works out a fee should not be the person who approves it (the Fees tab can require finance approval);
• the officer who reviews should not be the only person who decides on a significant licence;
• the system enforces maker-checker where money or sensitive decisions are involved: a proposer cannot approve their own

  proposal.

A worked example

For the "Example Vendor Permit":

1. Fill e-Service Form (Applicant)
2. Review Application (Case Officer)
3. Inspect Site (Case Officer)
4. Generate Invoice / Fees (Supervisor)
5. Make Payment (Applicant)
6. Verify Payment (Case Officer)
7. Decide route (System): fee above K10,000 goes to step 8, otherwise to step 9
8. Executive Decision (Executive)
9. Approve (Supervisor)
10. Generate Output Document (System): the permit
11. Notify Client (System)

The Decide route step keeps small permits quick while large ones get an executive decision.

Check and try the process

On the Service process tab, Check and try the process works on the open draft (or the live process when there is no draft):

• Check finds the errors that would block publishing: a person's step with no role, a step that continues at a

  missing or earlier step (a loop), a route with no default path, a condition on an answer the form does not have, a parallel approval with fewer than two approvers, or a step nothing leads to.

• Simulate runs the process with sample answers and a fee. The answers decide the routes; the start date and the

  working calendar decide the due dates.

• Compare shows how the draft differs from the live process.

Use the simulation to test every branch of a Decide route step before you submit the version.

What the citizen sees

The citizen does not see step names. My Workplace on the portal shows a plain status word for the case ("Received", "With the office - fees being worked out") and asks the citizen to act when a step is theirs, such as paying. Status notifications are sent as configured.

Check your understanding

• Which step type sends a case down different paths, and what must it always have?
• Which roles can perform an Executive Decision step?
• What do the dashed steps in the designer have in common?
• When would you mark a step as performed by another ministry?
• How can you test every branch of a route before submitting a version?
• Why should the officer who works out a fee not be the one who approves it?