1. Municipal Corporation ERP
  2. Features
  3. Requirements and evidence
Feature · Requirements and evidence

Requirements and evidence

Keep each service requirement and supporting document tied to the case it supports.

OverviewPending Requirements
Municipal Corporation ERP · Requirements and evidence

Pending Requirements

Approval conditions

New
ParentSequenceDescriptionSubmitted atOutcome
CSS-9396730Pending cr-28515 OctPending
CSS-5949770Pending cr-42020 OctPending
CSS-9030160Pending cr-50223 OctPending
CSS-8770170Pending cr-50212 OctPending
CSS-1065790Pending cr-10116 OctPending
6 of 6 records
Pending cr-285Case requirements · CR-83228
Pending
ParentCSS-93967
Sequence30
Submitted at15 Oct
Example screen with sample data

What you can do

Review the detail behind a service request

A case may need several pieces of information before a decision can be made. Requirement lines retain their sequence, description, source reference, observation date, quantity, unit and amount when those facts apply. The line also has an outcome: Pending, Accepted or Rejected. That outcome belongs to the line, allowing the team to see which part of the request still needs attention.

Supporting documents have a title, attachment, document date and external reference. Verification is recorded against the document with a named person. The case workspace brings the requirement strip and documents close to the current case. This makes the handoff to an independent reviewer more precise than a message saying an application is complete.

How the work is organized

  • Requirement lines. Keep each observation or requested item attached to the parent case and in its intended sequence.
  • Document evidence. Link the attachment to the same case, with its own verification state and verifying person.
  • Decision context. Retain the source reference and reason when a requirement is rejected or sent back for correction.

What to agree during setup

Agree which service requirements must be recorded as separate lines and which attachments support them. Choose a consistent way to enter source references so the operator and reviewer can locate the original submission. Decide who verifies documents and how the team handles a replacement attachment after a case revision. A verified document should be read with its date and external reference, rather than assumed to support every later revision automatically.

For a representative case, enter a line for each requested item and attach the evidence supplied by the applicant. Mark one line Accepted and leave another Pending while its document is checked. The operator should be able to explain the pending item without marking the entire case as decided. The reviewer should see which evidence was verified and by whom before recording a decision.

Check the handoff on an actual case

Open Pending Requirements and identify the parent case, line description and submission date. Open Documents to Verify for that case and check the document title, date and verifying person. Move back to Cases and Details to confirm the line outcomes and document state alongside the current revision. The reviewer can then determine whether the evidence supports approval, return or rejection of that revision.

If a line is rejected, record a reason that tells the operator what to address. If a new document is received, preserve its distinct source reference and verification state. The follow-up owner should be able to close the outstanding request with a resolution, while the previous line and case history remain available to explain the original decision.

What your team sees

  • Pending Requirements — Individual lines waiting for an outcome, grouped by parent case.
  • Documents to Verify — Supporting attachments awaiting a named verification action.

Follow the work through

What it keeps track of

Data model
Case requirements
Observation-level requirement, document and line detail captured against a service application.
Case documents
Uploaded and verified supporting documents and source evidence.
Cases
Requests, applications and cases submitted for a public service.
Decisions
Independent reviewer decisions recorded against an exact source revision.
Follow up actions
Assigned outstanding actions, corrections and outstanding requests for a case.
People
Staff, officers, reviewers and assigned team members.

Who uses it

Permissions
Municipal Corporation ERP Operator
Records requirement lines, documents and follow-up work.
Municipal Corporation ERP Reviewer
Reads the evidence and records the independent case decision.
Read Only Analyst
Reads authorized outcomes; Municipal Corporation ERP Administrator maintains service context.

Set up Municipal Corporation ERP your way.

Start free, then use Proto to change fields, steps and approvals before your team goes live.

How to get started