Move Resource Assignment

[pranavvarsh]

Move a Resource Assignment 

Shift the start (and, where needed, the duration) of an existing resource assignment without losing its allocations. 

Before You Begin 

Role required: resource_user or resource_manager 

The assignment must belong to an open task and must not have any actual hours captured against it for the period you want to move. 

Where You Can Move Assignments 

Move is available from three surfaces and uses the same underlying behavior: 

1. Resource Management (RM) Workspace 
   Open a resource card or board and choose Move from the row context menu in either the top tray (task-level rows) or the bottom grid (individual resource assignment rows). This is the primary interface for resource managers to shift assignments across working calendars. 

2. Project Workspace (PWS) 
   In the Planning grid for a project, choose Move from the row context menu on the assignment row. Project managers use this to adjust resource assignments when project timeline changes occur. 

3. Planning Item (Portfolio Planning) 
   When your instance has Portfolio Planning integrations configured and the property sn_pw.resource_assignment_auto_sync_enabled is turned on, changing a project's start or end date automatically moves the linked planning item's planned dates to match. Any resource assignment created against that planning item automatically moves to the new dates. This eliminates the need to manually Move each resource assignment after rescheduling a project — the cascade happens automatically. 

About Its Task 

The resource assignment dates honor the task dates. The start and end dates of the resource assignment stay within the task's start and end dates. 

When you move a resource assignment so that its new duration would extend beyond the task end date, the resource allocation dailies outside the task dates are cleared and the released capacity becomes available again. 

You cannot move a resource assignment if actual efforts have been captured for the work. Use the Show actuals toggle in the settings side panel to view the efforts captured via time cards. 

Resource employment dates (employee profile start/termination) are NOT validated by the Move action. You can move an assignment to dates that fall outside the resource's active employment window. However, no daily allocations will be created for days that fall outside the resource's employment period. 

Procedure 

1. Navigate to Workspaces > Resource Management Workspace (or open the Planning view in Project Workspace). 
2. Select the Resource cards icon and open a resource card. Alternatively, access a resource board from a widget. 
3. Select the chevron icon for the drill-down view of the tasks assigned to the resource. 
4. Select the row context menu (three vertical dots) for the required row and choose Move. 
5. In the Move assignment modal, enter or pick the new start date in the New start date field. 
   Note: The Task end date shown in this modal is displayed in your own time zone. If you're in a time zone ahead of UTC (for example IST), the date is computed from the task's localized value rather than its stored UTC value, so it always matches the task record you'd see elsewhere in the product. 

6. (Optional) Change the assignment status using the New status list. 
7. Select Confirm. 
   A confirmation message appears once the move completes. The board refreshes to show the new placement. 

 

Worked Example with Daily Contour Details 

A resource assignment for the Website Overhaul task is assigned to Grace Lee. The task duration is August 01, 2026 to August 31, 2026. 

Scenario 1: New Duration Extends Past Task End Date 

Original Assignment: 

Start Date: August 03, 2026 | End Date: August 07, 2026 | 
Lets assume hours are distributed based on user’s availability. Total hours = 23hours 

Date	Day	Hours
Aug 01	Saturday	0h (non-working)
Aug 02	Sunday	0h (non-working)
Aug 03	Monday	8h
Aug 04	Tuesday	4h
Aug 05	Wednesday	2h
Aug 06	Thursday	1h
Aug 07	Friday	8h
Aug 08	Saturday	0h

Move Action: Change start date to August 20, 2026 

Problem: If we naively shift the assignment (5 working days) from August 20, we would need to extend until August 26. But the task ends on August 31, so this fits. 
Now lets move the assignment to August 28. 

After Move : 

Start Date: August 28, 2026 | End Date: August 31, 2026 | Total: 12 hours (2 working days, effort reduced from 23h to 12h).

Therefore the assignment was clamped to honour task end date. 

Date	Day	Hours
Aug 28	Friday	8h
Aug 29	Saturday	0h (non-working)
Aug 30	Sunday	0h (non-working)
Aug 31	Monday	4h
Sept 1	Tuesday	0h (out of task date)

Key Takeaway: The system clamps the end date to the task boundary and the extra hours got removed. The 8 hours that would have been allocated beyond the task end date are permanently removed.  
Move functionality retains the contour. 

Scenario 2: Resource with Custom Schedule (Mon/Wed/Fri Only) 

Original Assignment (MWF schedule): 

Start Date: August 03, 2026 | End Date: August 12, 2026  

Lets assume hours are distributed based on user’s availability. Total hours = 21hours 
 

Date	Day	Assigned?	Hours
Aug 3	Monday	Yes	4h
Aug 4	Tuesday	No (custom)	0h
Aug 5	Wednesday	Yes	6h
Aug 6	Thrusday	No (custom)	0h
Aug 7	Friday	Yes	2h
Aug 8-9	Saturday - Sunday	No	0h
Aug 10	Monday	Yes	1h
Aug 11	Tuesday	No (custom)	0h
Aug 12	Wednesday	Yes	8h

After Move to August 19 with Custom Mon/Wed/Fri Schedule: 

Start Date: August 19, 2026 | End Date: August 28, 2026 | Total: 21 hours (preserved) | Contour : maintained |

Working Days Available: 3 per week (Mon/Wed/Fri only) 

Date	Day	Assigned?	Hours
Aug 19	Wednesday	Yes	4h
Aug 20	Thursday	No (custom)	0h
Aug 21	Friday	Yes	6h
Aug 22-23	Sat-Sun	No	0h
Aug 24	Monday	Yes	2h
Aug 25	Tuesday	No (custom)	0h
Aug 26	Wednesday	Yes	1h
Aug 27	Thursday	No (custom)	0h
Aug 28	Friday	Yes	8h

Key Takeaway: The system respects the resource's custom working schedule. Since Grace only works Mon/Wed/Fri, the effort moved based on the schedule of the user.  
Move functionality retains the contour. 

Scenario 3: Resource with Time-Off Inside New Range 

Original Assignment: 

Start Date: August 03, 2026 | End Date: August 07, 2026 | Total: 23 hours 

Date	Day	Hours
Aug 01	Saturday	0h (non-working)
Aug 02	Sunday	0h (non-working)
Aug 03	Monday	8h
Aug 04	Tuesday	4h
Aug 05	Wednesday	2h
Aug 06	Thursday	1h
Aug 07	Friday	8h
Aug 08	Saturday	0h

Move Action: Change start date to August 17, 2026 
 

Grace has time-off (vacation) on 20 August, 2026 (and time off is present in the property com.snc.resource_management.exclude_events_from_schedule) 

After Move (With Time-Off Days Excluded): 

The system skips time-off days and extends the end date to preserve the original countour of effort hours. 

Date	Day	Status	Hours
Aug 17	Mon	Working	8h
Aug 18	Tue	Working	4h
Aug 19	Wed	Working	2h
Aug 20	Thurs	Time-Off	0h
Aug 21	Fri	Working	1h
Aug 22	Sat	Weekend	0h
Aug 23	Sun	Weekend	0h
Aug 24	Mon	Working	8h

Key Takeaway: The system automatically skips time-off days and extends the end date as needed to ensure contour stays preserved and allocated only on days when the resource is available. 

Move functionality retains the contour. 

Capacity: The 24-Hour Daily Cap 

By default, the system caps daily allocation to 24 hours. If a resource is already booked elsewhere, the move respects that booking. 
 
Start Date: August 03, 2026 | End Date: August 07, 2026 | Total hours = 40 hours (8 hours each day) 

Example with Default Behavior (allocate_more_than_24hours_per_day = false): 

Grace already has 20 hours booked on August 20. The Move operation wants to allocate 40 hours by shifting dailies maintaining contour to new duration across 5 days (8 hours per day). On August 20, the system caps the allocation to 4 hours because 24 hours can be allocated at max for a day and 20 hours are already allocated. Therefore only 4 hours can be allocated out of 8 hours. 
Effort will reduce to 36 hours. 
 
Therefore allocation daily will look like 

Date	Day	Status	Hours
Aug 17	Mon	Working	8h
Aug 18	Tue	Working	8h
Aug 19	Wed	Working	8h
Aug 20	Thurs	Working -> hours reduced	4h
Aug 21	Fri	Working	8h

Example with Bypass (allocate_more_than_24hours_per_day = true): 

When this property is enabled, the 24-hour-per-day cap is removed entirely. The full 8 hours per day are allocated on August 20, even though Grace is already booked 20 hours that day (total = 28 hours). This property allows over-booking when necessary, but your organization should use this carefully as it may indicate resource conflicts. 

Employment Dates and Daily Allocations 

Important: Resource employment dates (hire date and termination date on the employee profile) are NOT validated by the Move action. You CAN move an assignment to dates that fall outside the resource's active employment window. 

Example: 

Grace's employment ends on August 19, 2026. You move an assignment to August 17-21. The Move itself succeeds. However, daily allocations will only be created for August 17-19 (within employment dates). No allocations will be created for August 20-21 (after her termination date). 

Daily Result: 

Date	Employment Status	Allocation Created?
Aug 17	Employed	Yes - 8h allocated
Aug 18	Employed	Yes - 8h allocated
Aug 19	Employed (last day)	Yes - 8h allocated
Aug 20	Not Employed	NO - no allocation
Aug 21	Not Employed	NO - no allocation

This is a system constraint to prevent allocating work for a resource when they are no longer employed. Monitor your employment dates carefully if you move assignments to future dates. 

Cost After a Move 

If a rate model is attached (to the project, or directly to an operational assignment) or the assignment carries its own rate override, moving the assignment recalculates cost for every allocation day using whichever rate is effective on that day. 

Example: Dated Rate Lines (Monthly Rate Change) 

A project has a rate model with two rate lines: 

• August 1-31: $100/hour 
• September 1+: $120/hour 

Grace's original assignment: 40 hours in August (Aug 3-7) at $100/hour = $4,000 cost 

After moving to August 27 (which extends into early September): 

Date	Hours	Rate	Cost/Day	Reason
Aug 27	8h	$100	$800	Aug rate
Aug 28	8h	$100	$800	Aug rate
Aug 29	0h (weekend)	$100	0	Aug rate
Aug 30	0h (weekend)	$100	0	Aug rate
Aug 31	8h	$100	$800	Aug rate
Sept 1	8h	$120	$960	Sep rate
Sept 2	8h	$120	$960	Sep rate

New Total Cost: $4,320 (instead of $4,000). Even though the total hours (40h) remain the same, the cost increased because some days are now billed at the higher September rate. 

Behavior Reference 

Move Within the Task Duration 

Situation	What Happens
New start inside task and duration fits inside	Assignment shifts to new range. Effort and per-day allocations redistributed.
New start inside task but duration extends past end	Assignment end clamped to task end. Effort reduced.
New start same as current start	Confirm disabled. Message: "Select a different Start date."
New start exactly task start	Allowed. Assignment starts on task start.
New start exactly task end	Allowed. Assignment compresses appropriately.

Move Outside Task Boundaries 

Situation	What Happens
New start before task start	Modal shows " New dates should be within the task duration dates. " Confirm disabled.
New start after task end	Modal shows " New dates should be within the task duration dates. " Confirm disabled.

Status Change During a Move 

The Move assignment modal includes a New status picker so you can update the resource status in the same action — no need for a separate Change Status flow. 

Common use case: A previously approved assignment needs to revert to pending when shifted to new dates so the resource manager re-approves the new window. 

Situation	What Happens
Leave New status as it is	Current status preserved. No update.
Pick different value in New status	New status applied to assignment and all cascaded children.
Change only status without new start date	Not supported. Confirm stays disabled until you pick new start date.

Edge cases with Employee Profile dates 
 

1. When employment end date is before task end date. 

This example shows how a move on a parent (group) assignment cascades to its child assignments, and what happens when a resource employment end date gets in the way. 

Setup 

• User1 has employment date January–March 

• User2 has employment date January–September 

• Group1 is the primary group for both User1 and User2 

• Project1 is planned for January–December 

• A group assignment is created on Project1 using Group1 with the date January-March 

Initial dates 

Assignment	Start	End
Parent (Group1)	January	March
Child – User1	January	March
Child – User2	January	March

Action: Move the parent assignment so it starts in February. 

Dates after the move 

Assignment	Start	End
Parent (Group1)	February	April
Child – User1	February	December
Child – User2	February	April

What happened 

The move keeps each assignment's original duration (3 months) and shifts the start to February. 

• User2: Feb–Apr fits inside their employment window (Jan–Sept), so no adjustment is needed. 

• User1: Keeping the 3-month duration would push the end to April, but User1's employment ends in March. Because the new end date crosses the employment end date, the assignment falls back to the project's end date instead of the calculated one. 

Important Note : Even though User1's assignment end date shows as December, the resource allocation daily records for User1 are only generated till March — because March is User1's employment end date. So the assignment's visible end date and the days actually allocated can differ. 
 
 
 
Same behavior on a user-based assignment 

A user-based (direct) assignment has no parent/child structure, but the date-adjustment logic is identical, because it operates on a single assignment against the resource's employment window. 

Example: User1 is employed January–March, and Project1 is planned January–December. A direct assignment for User1 initially runs January–March. 

Move the assignment to start in February: 

• The move keeps the 3-month duration, which would push the end to April. 

• April crosses User1's employment end (March), so the assignment falls back to the project's end date instead. 

• Even so, resource allocation daily records for User1 are only created through March, since that's the employment end date. 

So the takeaway is the same in both cases: the assignment's visible end date can extend past the employment end, but the daily allocations never do.

2. When employment start date is after task start date. 

This example shows what happens when part of a resource assignment start date falls outside the resource's employment dates, and how that affects a move. 

Setup 

• Project1 is planned January–December 

• User1 has an employee profile valid February–December 

• A resource assignment (RA) is created for User1 running January–March 

Because January is outside User1's employment window, no daily allocations are created for January. The dailies exist only for February and March. 

	Assignment span	Days actually allocated
Before move	January – March	February, March

Action: Move the resource assignment’s start date from January to February. 

What you might expect 

Since the move shifts the start forward by one month, you might expect the whole span (and its allocations) to shift by one month too: 

• Resource assignment span: February – April 

• Allocations: March, April 

What actually happens 

• Resource assignment span: February – March 

• Allocations: February, March 

Why this is correct

1. No dailies were ever created for January, because January was outside the employment window — so there was nothing in January to shift. 

1. The assignment's offset was 0 (there was no gap between the assignment start and its task start date). 

1. On the move, the dailies were re-anchored to start from February using that zero offset. So the allocations begin again at February rather than shifting a full month past it. 

The result is a February–March assignment with allocations in February and March, which is the expected behavior. 

UI Entry Points 

Triggering the Move Operation from the Workspace 
The Move action is available in both the Resource Management Workspace and the Project Workspace, and behaves identically in each. 

How to trigger it 
Open the ellipsis menu on a resource assignment row and select Move. 
 
Precondition: actual hours 

• If the assignment has actual hours captured against it, the move is blocked and an error is shown: "Cannot move a resource assignment for which actual efforts are captured." 

• If no actual hours are present, the Move modal opens. 

Using the Move modal 
In the modal, select: 

• the move date (required) 

• the assignment status (optional) 

Once the fields are valid, the Confirm button becomes active. 

What happens on confirm 
Clicking Confirm sends a scripted REST API call to: 

/api/sn_plng_att_core/planning_attribute/moveAssignment 
  

This routes to the ResourceAssignmentMoveSNC script include, specifically the moveResourceAssignmentFromWorkspace function, which carries out the move. 

Technical Entry Points and Functions 

The Move flow is triggered from multiple UI surfaces but uses the same underlying backend logic. Here are the technical entry points: 

Primary Script Include 

Component	Details
Script Include	ResourceAssignmentMove
Scope/App	sn_plng_att_core (Planning Attributes Core)

Primary Entry Point Functions 

Function Name	Purpose & Parameters
moveResourceAssignmentFromWorkspace()	Main entry point triggered from RM Workspace and Project Workspace Move modals.  Parameters: assignmentId, newStartDate, newStatus
isMovingAssignmentAllowed()	Pre-flight gate that validates if a move can proceed. Checks for actual hours and other blocking conditions before the Move modal opens.  Parameters: assignmentGr (GlideRecord)
moveResourceAssignmentsInTaskHierarchy()	Related but separate flow. Triggered when a task's dates change directly (not via Move modal). Cascades the date shift to all child resource assignments. Parameters: topTaskId

Limitations and Known Constraints 

• Resource employment dates not validated — you can move assignments outside employment window, but dailies won't create for those dates. 
• Resource board visible date range does not constrain Move. The visible range is UI convenience only. 
• Move not available on group child rows, resource plan rows, or operational resource plan rows. 
• Status values in excluded list not blocked from Move server-side; exclusion affects availability calculations only. 
• Closed or inactive parent task does not block Move. Moving an assignment whose task has been closed still succeeds.