Roles and permissions
Each role sees the cases and fields that belong to its task, and the check sits at the endpoint, not only in the interface.
Blueprint 02
Internal Operations Platform
One core process that currently lives in spreadsheets, email and single tools, rebuilt as one application with roles, workflow and a shared overview
Solution blueprint: a fully worked example system, not a delivered client project. The processes, architectures and metrics show how we would build such a system — they are not measurements.
Part of
Custom Business SoftwareStarting point
The problem.
A process that matters to the business sits in a spreadsheet, a shared mailbox and several separate tools at the same time. The overall status exists only when someone assembles it by hand, and responsibilities hold because people know them, not because a system enforces them. When someone is away or leaves the organisation, part of the process leaves with them.
Before · After
The same process, twice.
On the left, the process as it typically runs today. On the right, the same process once an application takes over the repetitive steps.
Today
How the process runs if nobody changes anything.
- 01Case reported by emailHuman
- 02Row added to spreadsheetHuman
- 03Responsibility agreed verballyHuman
- 04Documents dropped on shared driveHuman
- 05Queries sent to mailing listHuman
- 06Approval obtained by phoneHuman
- 07Posting triggered in ERPSystem
- 08Status list assembled for managementHuman
With NeXsoft
The same process, with the decision at one clear point.
- 01Case captured in the portalSystem
- 02Rule set assigns responsibilitySystem
- 03Required fields and deadlines checkedSystem
- 04Approval by the responsible managerHuman
- 05Handover to ERP and storageSystem
- 06Dashboard updates itselfSystem
The label Human marks the points where a person decides or enters something. System marks the steps the application takes over. The human approval deliberately stays in place — it is not optimised away.
Interactive
The process, station by station.
The walkthrough stops at the point where a person decides. It continues only once you approve.
Flow
Step 1 of 6
- Intakerunning
- Assignmentwaiting
- Processingwaiting
- Approvalwaiting
- Handoverwaiting
- Reportingwaiting
A new case is created in the portal or arrives through a connected source and receives its own number on creation, in this example M-0001.
The visualisation runs in your browser along a fixed sequence — nothing is uploaded, nothing is sent and no language model is called.
- A new case is created in the portal or arrives through a connected source and receives its own number on creation, in this example M-0001.
- The rule set determines from case type, site and value band which role is responsible, and records that role on the case.
- The responsible person works on the case in a form that shows only the fields belonging to this step.
- The manager sees the complete case including its documents and either approves it or sends it back with a reason.
- The application writes the approved data into the connected systems and files the documents in the agreed location.
- The dashboard shows the overall status by state, responsibility and age, without anyone assembling a list.
Features
What the system would need to do.
Every line is a commitment about future work — not a description of something that already exists.
Workflow with states
A case moves through defined states; which transition is allowed follows from the role, not from habit.
Data model instead of spreadsheet
Cases, participants, dates and documents are objects with relations, not columns in a file.
Approvals with an audit trail
Every approval records who granted it, against which version of the case, and with which note.
Documents on the case
Files attach to the case rather than to a folder tree, with versions and a visible link to the case.
Notifications with deadlines
Responsible people are notified on handover, on a query and on an approaching deadline, by email or in the portal.
Dashboard and export
The overall status is available as a view and as an export, so reporting is not rebuilt in a spreadsheet again.
Integration
What a system like this typically connects to.
Categories rather than vendor names — which product you run is decided by the system landscape you already have.
ERP or merchandise management
CRM
DMS or the existing file storage
Directory service for sign-in (SSO)
Email and calendar (Microsoft 365)
The department's specialist software through its interface
Architecture
How this would be built.
One example structure in layers. Not the only one possible — but one we can justify.
Interface
- Web application with views per role
- Forms generated from the data model
- Dashboard and export views
Application logic
- Workflow engine with defined state transitions
- Rule set for responsibility and deadlines
- Permission check on every endpoint
- Audit trail of all state and field changes
Data and documents
- Relational database with versioned migrations
- Object storage for attachments
- Full-text index across cases and documents
Integration and operations
- Connectors to ERP, CRM and storage
- Event queue with retry on failure
- Structured logs and error tracking with alerting
Metrics
How success would be measured.
These are the figures that would be measured during a project. Deliberately no values are shown — there is no measurement they could come from.
Cycle time per case
would be measured as the time between creation and completion, taken from the status log
Waiting time before approval
would be measured as the time a case spends in the state awaiting approval
Share of cases with a query
would be measured by the number of returns to an earlier state
Share of duplicate data entry
would be measured by the fields still transferred into a second system by hand
Usage per role
would be measured by active roles and cases handled per period
Expansion
Start small, then grow.
A project of this kind does not begin with the full build. It begins with the part that carries its weight soonest.
One process, in full
The first stage covers exactly the process that currently runs largely by hand: roles, states, approval and document storage on one data model.
Connections and reporting
Next come the connectors to ERP, CRM and storage, so the same data is not re-entered in a second system, and the dashboard replaces the hand-assembled status list.
Further areas and external participants
Later, adjacent processes can run on the same data model, and suppliers or customers can be given their own access with a restricted view.
Do you recognise your own process?
Describe the process that currently sits between spreadsheets and email in an initial conversation, and we will set out which part of it works as a first stage.
Solution blueprint: a fully worked example system, not a delivered client project. The processes, architectures and metrics show how we would build such a system — they are not measurements.