Synchronize Process Data with a Case Profile¶
Goal¶
Load editable data from the current case profile into a related process and write approved changes back to the same profile.
What You Will Learn¶
- read the current case profile in prework
- update only the intended profile subtree in postwork
- notify the case runtime after a profile change
Difficulty and Estimated Time¶
- Difficulty: Intermediate
- Estimated time: 20 minutes
Assumed Knowledge¶
You should understand channels, cases, related processes, prework, postwork, and XML nodes.
Required Reading¶
Prerequisites¶
- a test channel with cases enabled
- this definition added as a related process
- a case profile containing
TutorialProfile/Record
Example Overview¶
One case-handler task loads TutorialProfile/Record into Record, lets an authorised user edit Name and Status, then replaces only that profile subtree and signals the change.
Steps¶
Load the Profile in Prework¶
1 2 | |
Save the Approved Fields in Postwork¶
1 2 3 | |
Use a narrow subtree rather than replacing the entire profile. This preserves data owned by other related processes.
Close the Case Only on an Explicit Action¶
Add a Close Case action with a required comment, then close the current case only when that action was selected:
1 2 3 | |
Do not infer closure from a form field alone. The explicit action provides an auditable user decision and lets normal case authorization run in the current context.
How It Works¶
The related process runs in a case context, so $Case refers to the current case. Prework creates an editable process copy; postwork explicitly commits the selected subtree back to the profile.
Verify the Result¶
- Create a test case with the required profile nodes.
- Start the related process and confirm that the form loads the existing values.
- Change
Status, submit, and confirm that the case profile is updated. - Confirm that unrelated profile nodes remain unchanged.
- Select
Close Case, enter a comment, and confirm that the case is closed only after postwork succeeds.
Failure and Edge Cases¶
- Start without the expected profile subtree and confirm that the process reports a controlled configuration error.
- Attempt the task as an unauthorised user and confirm that case permissions are enforced.
- Run two edits against the same profile and define how conflicting updates should be handled.
- Force profile persistence to fail and confirm that the case is not reported as successfully closed.
Security and Portability Notes¶
$Caseis valid only in case context; do not silently create unrelated data when it is absent.- Limit the task role and form fields to data the user may view and change.
- Copy only the owned subtree and avoid logging personal profile data.
Download and Try It Yourself¶
Download the case-profile synchronization definition.
Troubleshooting¶
- Profile is empty: Confirm the related process runs from a case and the profile path exists.
- Changes are not visible: Confirm that postwork calls
$Case.ProfileChanged()after updating the subtree.