Assignments and substitutions

On approval the assignment-on-approval workflow fires: a code node creates an Assignments row (Resource, Project, Role, rate card resolved from Practice + start date, bill rate resolved from rate card rows and frozen on the Assignment, cost rate snapshotted from resource cost rate, allocation pct carried from the request) plus N assignment periods rows (one per week from start date to end date at the requested allocation pct). 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.

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 outgoing resource, incoming resource, effective date, 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 end date to effective date − 1, keeps it Active until the boundary becomes effective, and creates a new Assignments row + assignment periods for the incoming resource starting effective date.

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

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.

• Assignment Calendar. Open the current records for this module within your assigned role and permitted scope.