I’m looking for guidance on a Constellation use case involving assignment SLAs.
Scenario
I have an Ad-Hoc Assignment with an Assignment SLA configured.
When the Ad-Hoc Assignment is created, the SLA is also created and corresponding queue entries are generated.
The user opens the Ad-Hoc Assignment and updates the Due Date/Time.
Instead of completing the assignment, the user clicks Save for Later.
Based on the updated Due Date/Time, I need the Assignment SLA to be recalculated so that the Goal and Deadline timings are adjusted accordingly.
Challenge
In a traditional UI, we could potentially invoke custom logic on the Save for Later action to refresh or recreate the SLA. However, in Constellation, we do not have direct control to attach custom processing to the OOTB Save for Later action.
Questions:
Is there a recommended supported approach to refresh/restart the SLA when assignment properties are modified during assignment processing?
Has anyone implemented a similar requirement for Ad-Hoc Assignments in Constellation without custom code?
Any recommendations or best practices would be greatly appreciated.
In Constellation there isn’t a clean, supported hook on the OOTB ‘Save for Later’ action that lets you plug in custom SLA refresh logic the way you might do in traditional UI. ‘Save for Later’ is handled as a generic platform action and the Assignment SLA will not automatically recalculate Goal/Deadline just because you changed a due date field in the view.
Below are some alternate approaches you can consider-
Case level/ Stage level SLA instead of Assignment SLA: Store the user‑entered due date/time on a case property, Configure a case or stage SLA that reads that property in its Goal/Deadline calculations. So, when the user changes the due date and clicks Save for Later, the case data is updated, the case‑level SLA logic can re‑evaluate and adjust its targets.
Derived assignment property + periodic recalculation: Use a derived property or background process to periodically check for due‑date changes and adjust the SLA without tying directly to Save for Later. a declare trigger/ background agent/ queue processor runs, it: compares .DueDateTime to .SLAAnchorDateTime, if changed, updates the SLA (e.g. reschedules Goal/Deadline or restarts the SLA). The trigger/ agent runs and recalculate the SLA.
The Major Con with this approach is there are more moving parts: queue processor/agent, tracking properties and careful design to avoid race conditions.
Custom DX Component: Build a custom DX component or alternative action that replaces Save for Later in this specific flow and calls your own logic before delegating to the platform.
I’d advise you to be careful while opting for Approach #2 , as though it responds well to save for later and you have granular control, there is complexity and supportability as the declare trigger/ JS/ QP persists across the whole class, if misconfigured, they can run more often than you expect, impacting performance or interfere with other SLA behaviour. Also make sure you avoid tight coupling SLA behaviour with the platform activity and introduce maintainability issues.
Could you please trigger pxAdjustSLA in the Form Refresh settings and check if SLA is reflected once after the SLA Due date is changed in your assignment?
Some good suggestions above. I don’t have much more to add, except to question if the UX is the right approach?**
Save for later** is not Submit? That doesn’t align with the design system, Submit is when the form is done, we validate, post process etc.. If we started creating child cases, updating SLA’s or saving data objects to SOR’s on “save for later” then we start propagating transient information.
What if I then cancel or change stage? that information was never submitted but we’ve acted on it.
Thanks for the suggestion.
we observed a different scenario: when the form refresh triggers pxAdjustSLA, the user is prompted for Save for Later due to the assignment changes. If the user selects Cancel instead of confirming Save for Later, the SLA changes are still retained. In this case, we need the SLA updates to be reverted and the assignment to remain unchanged, since the user chose not to save the changes. Have you encountered this scenario or is there a recommended approach to handle it?
