KENYA · GUIDE 0596 · EDITION 4.2
No-code workflow building in Kenya: Operations and Quality Checks
Deliver the agreed result consistently
Automate a defined repetitive workflow with explicit triggers, approvals, exception handling, account ownership, and a manual fallback when connected services are unavailable.
The operating sequence for this offer is:
- Map the exact trigger, inputs, permitted actions and approval points, then agree platform running costs and demonstrate the workflow with fictional data.
- Test duplicates, failures and access permissions, seek approval before actions with external effects and keep error records visible to the responsible user.
- Hand over the workflow diagram, rollback and exception process, identify recurring platform charges and document who monitors and updates the automation.
Put acceptance into the job record
Workflow performs only approved actions and failures remain visible.
Run duplicate submissions, missing fields, declined approvals, and connection failures, checking that the workflow neither repeats external actions nor silently drops business requests.
Inspect at the point where a correction is still possible, then again at handover. Record rejected or incomplete output separately from accepted output. A completed task is not automatically an accepted task, and an invoice does not establish that the customer received the right result.
Measure real capacity
Time preparation, the main operation, transport, cleaning, approvals and correction as applicable. The slowest stage determines how much you can promise. Where two orders need the same person, space or equipment at the same time, resolve the conflict before confirming both deadlines. An additional enquiry should not erase a commitment already made.
| Operating checkpoint | Evidence for this business |
|---|---|
| Before starting | Automate a defined repetitive workflow with explicit triggers, approvals, exception handling, account ownership, and a manual fallback when connected services are unavailable. |
| During delivery | Test duplicates, failures and access permissions, seek approval before actions with external effects and keep error records visible to the responsible user. |
| At acceptance | Run duplicate submissions, missing fields, declined approvals, and connection failures, checking that the workflow neither repeats external actions nor silently drops business requests. |
| At the pilot review | Keep workflow versions, test cases, action logs, approval points, duplicate prevention decisions, fallback instructions, and owner demonstrations of handling an interrupted run. |
Keep a correction and escalation rule
When inputs, access, specifications or customer instructions change, pause the affected work and confirm the effect on time and cost. Do not quietly lower the acceptance standard to avoid a delayed delivery. Keep rework caused by your error distinct from a customer-requested change of scope and agree the remedy clearly.
A workflow becomes costly when a repeated trigger sends duplicate customer messages or a failed connection leaves staff assuming work was completed successfully.
Retain the minimum records needed to investigate a complaint without disclosing unrelated personal information. Use measured delivery and actual acceptance as the basis for expanding capacity, rather than the maximum theoretical output of a tool or production line.
Operating control points for this exact offer
| Sequence | Work method | Release checkpoint |
|---|---|---|
| 1 | Specify which data change triggers work and how duplicate events are recognised by RequestID. | Direct spreadsheet edits may need different event configuration than app edits. |
| 2 | Use five non-personal test requests and explicit required fields. | No real customer data enters a broadly shared prototype. |
| 3 | Create internal task only for eligible state and store an idempotency/completion marker. | Retry must not create a second task for the same request. |
| 4 | Run valid, missing owner, duplicate, changed state and failed task cases. | Inspect execution evidence; free-account test email restrictions are not misdiagnosed as production delivery. |
| 5 | Owner practises pausing bot, correcting one request and safely retrying. | Check actual subscription/permissions before relying on scheduled/external actions. |
Do not substitute a tick for an observation: record the count, measurement, approved sample or evidence reference used at each checkpoint. Mark unresolved work as held and identify who can approve the recheck.
Diagnose a failure before repeating it
| Observed symptom to investigate | Check the cause | Proposed response |
|---|---|---|
| Two tasks for one request | Check event retries/key marker. | Fix idempotency and reconcile duplicates before resuming. |
| Spreadsheet edit triggers nothing | Check supported event source/configuration. | Use documented trigger method and retest. |
| Bot fails silently | Inspect execution monitor and required fields. | Route failure to visible owner queue; do not mark request completed. |
These are diagnostic prompts, not proof of the cause in a real incident. Separate suspect output, record any correction and repeat the relevant acceptance check. Link rejected units, rework time, replacement materials, customer credits and collection delays to the actual job result.