My Requirement: When an identity is terminated, I need to clear every Work Reassignment involving them, in both directions:
- **As delegator** (they reassigned their own work out) — easy: `GET /reassignment-configurations/{id}` → `DELETE /{id}/{configType}`.
- **As delegatee** (someone else reassigned work *to* them, so they’re the `reassignedToId` on another identity’s config) — this is the gap. No endpoint looks up “who reassigned to this identity,” and the list endpoint takes no `filters` — it just returns the whole org’s configs in one shot. (Note: those deletes use the **owner’s** id + configType, not the terminated user’s.)
Two options I’m weighing, both kept inside ISC (no external PS script):
-
Audit search:**** `name:“Create Work Reassignment Passed” AND (target.name OR actor.name = “”)`, then DELETE per event. Problem: the create event is point-in-time. If the config was later repointed to someone else, I’d delete a still-valid reassignment. Old permanent ones may also have aged out of search.
-
List + filter:**** `GET /reassignment-configurations`, keep configs where `targetIdentity` = terminated user, DELETE those. Live and complete, but looping the full array risks the ~1000 workflow loop cap.
Questions:
1. Any supported reverse-lookup by 'targetIdentity`, or `filters` planned on the list endpoint?
2. In a Workflow, has anyone filtered the returned array to matches with a JSONPath predicate (e.g. `$[?(@.configDetails[?(@.targetIdentity==‘’)])]`) and looped only the matches, to dodge the loop cap?
3. I’m leaning toward a hybrid: use the audit search as an *index* to find candidate owners, then re-`GET /{ownerId}` and DELETE only if `targetIdentity` still matches — killing the stale-event problem. Sane, or overcomplicated?
Curious how others handle reassignment teardown at termination. Thanks!