Process Definition
- Process Starting Event
- Completion Outcome
Plan a custom web application around the work people need to complete.
Use this product pattern when software supports a specific business process that does not fit a more focused guide. Start with the records, decisions, handoffs, and exceptions that determine whether the work is completed correctly.
A custom web application is not a generic website with more forms. Its dedicated Detailed plan path captures the process boundary, work records, states, participants, routing, decisions, exceptions, corrections, queues, discovery, communication, reporting, and automation. Use custom requirements only for the domain rules that remain unique after those choices are made.
- Model the core records, states, owners, and decisions before designing screens.
- Include exception and correction paths alongside the happy path.
- Use reporting and automation to improve the workflow, not merely reproduce it.
Supported Decisions
What the workspace can actually scope
These decision areas and option sets come from the application-type specs used by the workspace.
Records & Workflow
- Primary Work Record
- Workflow State Model
- Related Record Structure
Participants & Responsibility
- Participant Scope
- Operational Routing Pattern
Decisions & Exceptions
- Decision Path
- Exception Resolution Pattern
- Correction Model
Operations & Insight
- Operational Queue Model
- Record Discovery Pattern
- Workflow Communication Pattern
- Operational Reporting Focus
Rules & Automation
- Rule Execution Boundary
Planning Signals
What to keep visible while scoping
These notices are generated from the same priority and mapping files used by the workspace.
High-priority choices
-
Required Process Starting Event
The process starting event establishes a clear first-release boundary and prevents the application from absorbing unrelated work.
-
Required Primary Work Record
The primary work record gives states ownership decisions and reporting one consistent operational subject.
-
Required Workflow State Model
The workflow state model must reflect real progress including valid branches and completion conditions.
-
Recommended Exception Resolution Pattern
Exception resolution should be planned alongside the normal path so staff can recover without side-channel work.
Related scope notices
-
Notice Workflow State ModelWhen: Branching States, Parallel Workstreams, Configurable State Machine
A non-linear operational state model should align with the core workflow-complexity choice.
-
Notice Related Record StructureWhen: Cross-Process Record Graph
Cross-process records should align with the required data-lineage depth.
-
Notice Participant ScopeWhen: Staff + Partners, Mixed Internal and External
External operational participants should be represented in the core user-type model.
-
Notice Operational Routing PatternWhen: Rules-Based Routing
Rules-based work routing should align with the core background-processing model.
-
Notice Decision PathWhen: Sequential Approval, Conditional Approval Chain
Complex domain decisions should align with the admin approval workflow.
-
Notice Exception Resolution PatternWhen: Specialist Queue, Rules + Human Review
Operational exception resolution should be visible in the admin dashboard focus.
-
Notice Correction ModelWhen: Correction Record, Compensating Action
Formal corrections should align with the selected audit and lineage depth.
-
Notice Record Discovery PatternWhen: Search + Filters, Saved Views, Role-Based Workspaces
Operational record discovery should align with the core search capability.
-
Notice Workflow Communication PatternWhen: Event Notifications, Role-Based Alerts, Escalation Notifications
Workflow communication should align with the selected notification channels.
-
Notice Operational Reporting FocusWhen: Ageing and Bottlenecks, Outcomes and Quality, Multi-Process Performance
Operational reporting depth should align with the core reporting capability.
-
Notice Rule Execution BoundaryWhen: Auto-Update Low-Risk Work, Auto-Route and Notify, Straight-Through Processing
Automated operational rules should align with the core business-rules implementation.
Draw the process boundary before listing features
Custom applications become difficult when the project tries to absorb every spreadsheet, inbox, approval, and surrounding system at once. Define the event that starts the process, the result that ends it, the people responsible in between, and the information that must remain authoritative. That boundary gives the first release a finish line.
- Name the trigger, completed outcome, and authoritative record for the process.
- Map the few state changes that represent real progress.
- Keep neighboring processes outside the first release unless the workflow cannot finish without them.
Plan roles, exceptions, and corrections as core behavior
Operational software is judged when reality does not follow the happy path. Missing data, duplicate records, rejected approvals, changed ownership, late responses, and incorrect status all need a clear route back to a trustworthy state. If only the normal flow is designed, staff will recreate the old process in side channels.
- List the high-frequency and high-cost exceptions before polishing the normal flow.
- Connect permissions to specific responsibilities and decisions.
- Make correction history visible wherever accountability matters.
Use integrations to preserve one source of truth
Most custom applications sit between existing systems. Define which system owns each important field, when data moves, what identifier connects records, and what users should see when synchronization is delayed or fails. A first release can use a simple import or export when real-time integration is not necessary for the outcome.
- Assign ownership for every shared record and important field.
- Choose batch, manual, or real-time exchange based on workflow need.
- Prioritize reports that trigger action or reveal blocked work.
Automate only the rules the team can explain
Automation creates value when a stable rule removes repeated work. It creates risk when unclear policy is hidden inside code. Capture the condition, action, owner, notification, and recovery path for each automated decision, and keep a manual review route for cases the rule cannot handle confidently.
- Automate repeated rules with clear inputs and outcomes.
- Expose why an automated action occurred and how it can be corrected.
- Treat unresolved policy as a product decision, not an implementation detail.
Decision Criteria
What To Evaluate First
Use these questions to decide which supported options deserve attention before a project is scoped.
- Is the first-release process boundary narrow enough to complete end to end?
- Are records, states, owners, permissions, and exception paths explicit?
- Does each integration have a clear source of truth and failure response?
- Will reporting and automation help users act, recover, and improve the process?
Call To Action
A custom application succeeds when the process becomes clearer, not merely digital.
If the workflow boundary, ownership, exceptions, system connections, and recovery paths are explicit, the product can remove real operational friction without becoming an unbounded replacement program.