These cookies are required for the website to function properly. They ensure security, enable basic features like page navigation, and store user session data. You cannot disable these cookies.
- Municipal Corporation ERP
- Features
- Delivery and corrections
Delivery and corrections
Trace execution attempts, delivery references and corrective work for a decided case.
OverviewReturned Decisions×
Municipal Corporation ERP · Delivery and corrections
New
Returned Decisions
Decisions
| Case | Reviewer | Source revision | Reason | Decided at | |
|---|---|---|---|---|---|
| CSS-71469 | 850 | Returned dcs-665 | 20 Oct | ||
| CSS-77666 | 760 | Returned dcs-597 | 08 Oct | ||
| CSS-58990 | 710 | Returned dcs-954 | 09 Oct | ||
| CSS-27258 | 570 | Returned dcs-481 | 26 Oct | ||
| CSS-86855 | 20 | Returned dcs-162 | 05 Oct |
6 of 6 records
Returned dcs-665Decisions · DCS-13147
CaseCSS-71469
Source revision850
Decided at20 Oct
What you can do
Follow the result to its source
A decision is followed by delivery work on the case. The case can retain a delivery reference and completion date. Operation runs identify the case revision and operation key used for an execution. Ordered steps within a run retain action names, input and output references and any external receipt evidence. Execution attempts record when an action was tried, its status and any provider reference or failure reason.
This detail helps the team distinguish a case marked Decided from one with a confirmed delivery. An attempt can be Queued, Running, Succeeded, Failed or Unknown. A run can also need reconciliation. An unknown outcome should lead staff to inspect the external receipt or provider reference before they try to settle the case’s status.
How the work is organized
- Run identity. Keep the operation key and source revision with the case so a repeated action can be recognized.
- Step evidence. Read the ordered step trace and external receipt evidence alongside the outcome.
- Named correction. Assign a follow-up action with a due date, status and resolution when work remains.
What to agree during setup
Agree who confirms delivery and what external reference counts as evidence for each public service. Decide how the team investigates a failed or unknown attempt, and who may retry an action. A later correction should be visible as a successor revision with its own review. If an earlier delivery is superseded, record the compensating follow-up so the team knows what remains to be resolved with the recipient or connected system.
For a representative case, record the approved revision’s operation run. Check its steps in order and compare the final receipt with the provider reference. If a step failed, leave the failure reason available to the person assigned to resolve it. Once the action succeeds, record the case delivery reference and completion date. A subsequent change should explain its relationship to that delivery rather than overwriting the original outcome.
Check the handoff on an actual case
Open Cases and Details on a decided case. Read its operation run, step trace and attempts before using the delivery reference. Then open Failed Runs and Execution Exceptions to make sure the same operation is not unresolved elsewhere. If an attempt is Unknown, ask the assigned person to reconcile the provider result. Record an explicit follow-up rather than treating a repeated click as proof of success.
For a corrected case, compare the earlier source revision, decision and state history with the successor. The reviewer should decide the successor on its own evidence. The operator should see the compensating work in Open Follow-ups and close it with a resolution only after the actual external consequence has been addressed.
What your team sees
- Failed Runs — Case-linked operation runs needing investigation or reconciliation.
- Open Follow-ups — Outstanding corrective work with an owner and due date.
- Execution Exceptions — Failed or unknown attempts with provider references and reasons.
Follow the work through
See delivery and follow-up and case history.
What it keeps track of
Data model- Cases
- Requests, applications and cases submitted for a public service.
- Decisions
- Independent reviewer decisions recorded against an exact source revision.
- Operation runs
- Workflow-maintained execution runs with operation key, input hash and persisted result reference.
- Operation steps
- Ordered steps inside an operation run with input, output and external receipt state.
- Execution attempts
- Each recorded attempt to execute an approved action for a service application.
- Follow up actions
- Assigned outstanding actions, corrections and outstanding requests for a case.
- Case state history
- Immutable workflow-written status transition history for each case.
Who uses it
Permissions- Municipal Corporation ERP Operator
- Follows the assigned case and corrective action.
- Municipal Corporation ERP Reviewer
- Decides a changed revision.
- Municipal Corporation ERP Administrator
- Reads execution provenance.
- Read Only Analyst
- Reads authorized outcomes and exceptions.
Set up Municipal Corporation ERP your way.
Start free, then use Proto to change fields, steps and approvals before your team goes live.