One record, three workspaces

Where the handover breaks

A customer adds a preference by email and then calls about scheduling. The form, inbox and calendar each hold part of the story. A single source gives core information a defined home while each role gets an appropriate workspace.

From incomplete to ready to plan

Consider a fictional maintenance request, V-104. The customer selects a location and preferred week, but the installation type is missing. Its status is therefore “information needed”.

Once that detail is added, the planner can prepare a proposal. After approval, the technician receives the relevant work information and appointment. An internal pricing note remains restricted. This is a process example, not an existing maintenance customer.

Control the transition

Who may mark a request complete? When may a date be confirmed? Which change needs approval again? These rules belong in the data model and permissions, not just on button labels.

What has been built

A working technical example connects public information, personal preferences and staff tasks around shared records. Matching separates hard conditions, preferences and missing information. Unknown does not become a positive match, and evidence remains visible for each criterion.

This pattern is useful for custom development. Rules and weights from another sector must be configured and tested again. A score is not a predicted probability of a successful job.

Integrate without new confusion

Decide which system owns a date, customer identifier or amount. Test duplicate input, rejected updates and simultaneous changes. API access and data rights determine feasibility. Start with a handover such as enquiry to scheduling and verify context, roles and recovery.