Symba Workflow separates preparation from review. This supports controlled handoffs between staff members and keeps each workflow's history available for audit and follow-up.
The workflow list opens with My work, All types, and All phases selected. Authorized staff can also switch to Available work or All work. These screens also show All types by default and include every workflow type the staff member is authorized to process, review, or view. Use the workflow type, phase, outcome, attention, and office filters to find relevant workflows. Filter selections remain available while navigating within the same signed-in browser session.
The workflow list identifies the subject of each workflow. A subject is the client, group, or other entity that the workflow concerns. The subject can differ from the external person who started or participated in the workflow.
The workflow list uses detailed lifecycle filters for operational search. The workflow detail presents the staff-facing lifecycle with separate meanings:
A failed or uncertain attention state does not by itself mean that the workflow was rejected. Open the workflow to review the current step, external record status, failure information, and available recovery actions.
Open a workflow to review its collected information, linked subjects, dependencies, and history. Depending on the workflow type and lifecycle, authorized staff may be able to:
An individual loan application started in Symba USSD may arrive with details saved but without a linked client. This means the channel could not identify exactly one active client, not that the workflow failed. Match the applicant or create the required related client-onboarding workflow before continuing.
The available actions and any blocker explanation come from the current workflow state in Symba Workflow. Symba Portal also applies your authorizations and the organization's review policy before showing an action.
Every workflow detail includes a readiness checklist. The checklist uses the same layout for all workflow types, but its items reflect the workflow type. For example, a loan may require application details, client selection, related client onboarding, and a registration fee. Client onboarding may require application details, applicant consent when terms are configured, client provisioning, a registration fee, and verified client-detail synchronization.
The checklist and blocker explanations come from Symba Workflow. When all required items are complete, authorized staff use "Submit for review". Subject selection, related workflow completion, confirmed payment, and other system events update readiness automatically. There are no separate "Submit application" or "Start completion" staff actions.
An authorized reviewer can approve or reject a workflow that is ready for review. Organizations may require the reviewer to be different from the staff member who submitted the workflow.
For either supported workflow type, a reviewer can request a correction instead of making a final decision. The workflow returns to Preparation with the reason visible to staff. Authorized staff make the permitted changes and resubmit it for review.
Approval or rejection may start an action in Symba Microbanking, such as activating or rejecting a client or approving or rejecting a loan. The workflow remains in the Finalizing phase while the action is in progress.
The workflow reaches the Finished phase only after the required external action is confirmed. The workflow detail screen shows the authoritative Symba Microbanking status separately from the Symba Workflow lifecycle.
If an action cannot be completed because the configured product or Microbanking record does not match the workflow, Symba Workflow shows Failed attention at the current step. Correct the underlying issue before retrying. Uncertain payment or provider states must be investigated rather than retried as a new operation.
History records lifecycle changes, data updates, assignments, subject links, review reasons, external actors, and confirmed external actions. An actor records who performed an action, while a subject records the entity the workflow is about. Use history to distinguish a requested action from an action that was confirmed by another product.