DOSS: workflows over shared operational data
What DOSS’s public workflow and master-data surfaces reveal about triggers, shared records and the boundary between automation and business state.
- Shared record
- Trigger and conditions
- Recorded decision
Investigation question
What makes an operational workflow more than a sequence of API calls? DOSS’s public descriptions put shared records alongside event- and schedule-driven automation. This investigation examines the implications without presenting marketing descriptions as proof of internal implementation.
Observed
DOSS describes workflows that connect operational records and decisions, including purchase approvals, order routing and document matching. Its master-data surface names shared business entities such as products, suppliers and bills of materials. These descriptions emphasize work performed over common data rather than unrelated copies in each module. The cited pages are public product documentation. They establish the advertised model and examples; they do not provide a public execution trace proving scheduling, persistence or isolation behavior. That evidence distinction matters when reasoning about configurable enterprise software.
Inferred
If two workflows read the same supplier or product, a change to that record can alter both workflows’ outcomes. The important design question becomes dependency management: which automations depend on a field, what value do they observe, and who can change it? This follows from shared data; it does not prove a particular dependency engine. Similarly, “approval” should be treated as business state with an authorized transition, not merely a notification. A useful model separates the trigger, the record under review, the decision and any subsequent external action. Replaying a trigger should not silently manufacture a new business decision.
Unknown & limitations
No authenticated DOSS workspace or proprietary client bundle is published here. Workflow retries, concurrency, audit history, schema-change handling and permission enforcement were not reproduced. The conceptual diagram is an analytical model of the public offering, not verified backend topology. An implementation evaluation should request direct evidence for these operational guarantees rather than infer them from a feature name.
Domain & data models
Conceptual sequence: shared record → trigger → conditions and decision → recorded outcome. A supplier belongs to master data; a purchase order refers to that supplier; an approval is an outcome on the order. Keeping those identities distinct helps explain what an automation changed and why.
Workflows & state machines
Illustrative example: a purchase order references a supplier and a requested amount. A workflow starts when the order reaches a review state, checks the relevant business conditions, and records an approval or rejection before the next step. If supplier data changes during review, an operator needs to know whether the workflow uses a snapshot or current values. The public material does not settle that question. A useful demonstration would inspect one order before and after its trigger, record the rule inputs, repeat the same trigger, and inspect the decision history. Then change one referenced field in a controlled test and observe whether an in-flight workflow changes. These tests distinguish actual behavior from what a workflow diagram suggests.