Assignments and substitutions

Assignment generation

On approval the assignment-on-approval workflow fires: a code node creates an Assignments row (Resource, Project, Role, RateCard resolved from Practice + StartDate, BillRate resolved from RateCardRows and frozen on the Assignment, CostRate snapshotted from Resources.CostRate, AllocationPct carried from the request) plus N AssignmentPeriods rows (one per week from StartDate to EndDate at the requested AllocationPct). The workflow then writes the Resource into the matched pm-projects project as a project member via the connected record service so the team appears in the project workspace. The Resource and Project Manager are emailed.

Substitutions

When a Resource needs to come off a project mid-flight (resignation, medical leave, reassignment, performance swap, client request), the Project Manager (or Resource Manager) proposes a Substitutions row with OutgoingResource, IncomingResource, EffectiveDate, and Reason. On independent approval (Status: Proposed → Approved), the workflow rechecks incoming capacity and the current assignment revision, then atomically truncates the original Assignment’s EndDate to EffectiveDate − 1, keeps it Active until the boundary becomes effective, and creates a new Assignments row + AssignmentPeriods for the IncomingResource starting EffectiveDate.

Assignment close-out

Daily, assignment-end-cleanup flips every Assignments row with EndDate < today AND Status: Active to Status: Completed (or Substituted for an approved effective replacement), freezes the trailing AssignmentPeriods to Status: Frozen, and recomputes the Resource’s forward WeeklyCapacity to release the freed AllocatedHours. The Resource is now visible to skill-match-suggester for the next request.

Replace a resource without losing the earlier weeks

A substitution starts from the original assignment and a specific effective date. The outgoing resource must match that assignment, and the incoming person must be a different eligible resource. Recheck the incoming person’s capacity before accepting the replacement; an open request is not enough. A future handoff retains the outgoing person’s booked hours before its effective date. In a split week, each person carries only their agreed days, so the change neither frees already committed time nor books the whole week twice.

Split the approved date range at the boundary in one transaction. Earlier weeks and their source-approved actuals remain attached to the original assignment. Later planned periods move to the new assignment once, with no duplicated allocation in the effective week. A repeated approval returns the same replacement identity.

The project membership connection is a separate outcome. If the delivery app times out after accepting the request, keep the original membership command key and reconcile it. The staffing team can see that the local assignment exists while the external membership is still unresolved. Repeating a new command would risk duplicate project memberships and notifications.