1
Different Trade Types
Employees may give away a shift, exchange shifts, or withdraw a pending request.
How a seemingly simple shift-swap feature evolved into a flexible workflow architecture supporting employee eligibility, competing responses, multi-manager approvals, operational day parts, and transactional schedule changes.
Real-world scheduling introduces qualifications, competing responses, management responsibility, operational boundaries, approvals, revalidation, and audit requirements.
While developing Week at Work, the shift trade feature was designed around an important architectural principle: a trade represents a workflow, not simply a database update.
That distinction allowed the architecture to support shift give-ups, employee-to-employee swaps, pickup responses, qualification-based eligibility, multi-manager approval, manager notes, and a complete history of how each scheduling change occurred.
Model the workflow that produces the scheduling change—not just the final scheduling change itself.
The design needed to accommodate several different employee and management workflows without creating separate systems for each scenario.
Employees may give away a shift, exchange shifts, or withdraw a pending request.
Employees accepting a shift must satisfy its position, training, qualification, and business requirements.
Multiple employees may respond to one trade before the requester selects the preferred response.
A trade might require one manager approval, any manager from a pool, or several independent approvals depending on the trade type and which day parts are affected by the trade.
Different managers may be responsible for different shifts or different periods within the same shift.
The platform needs to preserve who made each decision, why it was made, and how the schedule ultimately changed.
A trade request represents intent. Responses represent individual proposals for satisfying that intent.
This one-to-many structure allows several employees to respond without mutating the original request. For a simple give-up, the responding employee does not need to offer another shift. For a swap, the response identifies the shift being proposed in exchange.
Not every employee is eligible to work every shift. Rather than embedding qualification logic into the trade tables, employee qualifications and shift requirements remain independent domain concepts.
The qualification system determines whether an employee can work the shift. The trade workflow determines whether the proposed change should proceed.
Storing ApprovedBy and ApprovedAt on the request would fail as soon as multiple managers became involved.
The requirement belongs to the approval group. Individual approval records represent the managers capable of satisfying that requirement.
Alice's shift and Bob's shift may fall under different management responsibility, so approval requirements attach to the shift being evaluated rather than to the swap globally.
Shift #1001
Shift #2004
Both approval groups must be satisfied before the employee assignments can be exchanged.
Week at Work already understands operational day parts. The approval workflow can use those same boundaries to determine management responsibility.
Reusing an existing domain concept avoids creating a second representation of the same operational boundary.
Manager task dashboards cross several domains, making them a natural fit for CQRS-style application queries rather than a repository belonging to one aggregate.
Trade request screens use a similar pattern. Requests, responses, and approvals can be returned as separate result sets in a single database round trip and then grouped by the application.
This avoids massive joined result sets containing duplicated request data while retaining the performance benefits of efficient infrastructure queries.
Alice offers Shift #1001 for trade.
Bob's qualifications are evaluated against Shift #1001's requirements.
Bob proposes Shift #2004 in exchange.
Alice accepts Bob's proposed swap.
The application evaluates both shifts, applicable day parts, and eligible managers.
Each required approval group reaches a decision, preserving manager notes and timestamps.
Qualifications, shift state, and other critical constraints are checked again before commit.
Employee assignments are exchanged atomically.
Approval history and assignment changes are recorded for future review.
Requests, responses, selections, approvals, and completion are meaningful business states—not implementation details.
Qualification rules remain independent from the trade workflow so each can evolve independently.
Approval groups model what must be approved while approval records identify who may satisfy that requirement.
Existing day parts model operational boundaries and can therefore help determine management responsibility.
Current state answers what is true now while audit data preserves how the system reached that state.
CQRS-style read queries enable efficient task dashboards without distorting transactional domain models.
New approval scenarios can primarily be introduced through business rules rather than database redesign.
The difficult part of scheduling software isn't storing the schedule—it's accurately modeling the rules and human decisions that are allowed to change it.
See additional software architecture, product development, and engineering projects.