A customer calls to change the delivery address on an order. Your colleague finds the order, checks the request, changes the address and tells the customer what happened. That sounds like one job. How many tools does it take to finish it?
When you scope an internal admin system, start with a job like this. Decide what the person needs to see, what they may change and how they know the change worked. That gives you a much clearer brief than a list of dashboards.
Choose a job you can follow from start to finish
Take a fictional repair workshop that returns repaired equipment to customers. A customer asks for their item to be sent to a different address. The workshop keeps its repair orders in one system and books deliveries through another.
For this example, the repair-order system holds the accepted return address for that particular order. The dispatch service holds the shipment booking and confirms whether it can still be changed. Updating the customer's general contact details would be a separate decision.
Write down where each fact belongs. If two screens show different addresses, which record should staff rely on, and who should resolve the difference? Putting both on the same page leaves that question open until you decide.
Microsoft's guide to building model-driven apps treats data, business processes, app screens and security roles as separate parts of the work. It describes Power Apps, but it offers a useful planning reminder: choosing the screens is only part of defining the job.
Give each person the part they need
Before drawing the workspace, outline the roles, tasks and permitted actions. Here is a possible division for our fictional workshop:
Customer service
Sees address-change requests and the relevant order. Can request a correction after the required customer checks. Cannot mark a parcel as redirected.
Dispatch staff
Sees orders waiting for dispatch and accepted address changes. Can prepare a shipment or deal with a failed change, within the agreed rules.
Operations manager
Sees unresolved requests and how long they have been waiting. Can assign someone to handle an exception. This role need not include permission to edit every order.
These are proposed responsibilities, not a ready-made permission policy. Your own rules may require approval for some changes or restrict access to particular customer records. Both the visible controls and the system accepting the change need to respect those rules.
A manager's summary and a clerk's work queue can belong to the same application while serving different purposes. Let the next job determine the view.
Walk through the address correction
Find the request. Put the change request in a queue that someone owns. Show which repair order it concerns, when it arrived and whether anyone is already dealing with it. A note buried in the customer's history is easy to leave unfinished.
Check what can still change. Show the order's current return address and the shipment's latest known status. Make clear where those details came from and when they were checked. If dispatch information is unavailable or too old to rely on, the person needs to know that before promising a change.
Make the permitted change. After the workshop's customer checks and any required approval, an authorised colleague can submit the new address. The design should explain whether this updates the repair order, requests a change to an existing shipment, or does both as separate steps.
A useful admin workspace tells someone what needs doing, gives them the information and permission to do it, and shows whether it actually happened.
Wait for the right confirmation. Saving an address in the repair order does not confirm that the dispatch service accepted it. Show the two results separately. A request waiting for a response should remain pending, with enough information for staff to explain the situation to the customer.
Leave a useful history. Specify which events need recording, such as who requested and approved the correction, the old and new values, and the dispatch response. Decide who may see that history and how it will be checked. The presence of a history tab alone tells you little about which events it contains.
Give exceptions a destination. If the parcel has already left, the dispatch service refuses the change or the connection fails, send the unresolved request to a named person or team. Explain what they should check before trying again, so an uncertain response does not lead to repeated actions.
Decide what the connections must translate
Different systems may use different meanings for an order status or address. Microsoft's architecture guidance on translating between systems explains this problem and the work involved in maintaining that translation. It describes one technical pattern, not a component every admin system needs.
For the workshop, the practical question is simple: what exactly does each system mean by “changed”? Agree the fields, status meanings, confirmations and failure handling before treating the connection as finished. A single workspace can still depend on several systems doing their own part.
Turn the walkthrough into a brief
For each job you want to include, record the role, starting queue, source of the information, permitted action, confirmation, history and exception owner. Include the ordinary path and an awkward case, such as a shipment whose address can no longer be changed.
We build custom business software. Bring a walkthrough of the work you want staff to complete, including the part that currently gets stuck. The scope and terms of a possible project can then be discussed around that work.
Questions about a shared admin workspace
Does one workspace mean replacing every system?
No. It can bring together information and actions from existing systems. Decide which system holds the accepted record for each fact and which system must confirm each action. A shared view does not settle those decisions.
Should everyone see the same controls?
Give each role the information and actions its job requires. A manager may need a summary of unfinished work, while customer service needs an individual request. Sharing a workspace does not require sharing every permission.
What should happen when a change cannot be completed?
Keep the request visible with a clear status and a named person or team responsible for the next step. Explain what is known, what still needs confirmation and whether another action is safe. Do not show a requested change as completed before the responsible system confirms it.
