I’m not sure how the loopback connector would help for this ask or probably I might’ve misunderstood
@RAKGDS Although I don’t have a readymade workflow template available for this ask, below is how I would approach this workflow use case:
- Trigger:
Use the Identity Lifecycle State Changed trigger with the conditionlifecycleState == "terminated" or "inactive"(whatever is applicable as terminated in your tenant). This ensures the workflow starts only when an identitity’s lifecycle state changes to terminated. - Get Terminated Manager Details:
Add a Get Identity action to fetch the terminated identity’s record and save it as terminatedManager into a variable - Get Terminated Manager’s Manager:
Use another Get Identity action to retrieve the terminated identity’s manager using{{terminatedManager.manager.id}}, and store it into a variable as managerOfManager. - Find Pending Certifications:
Add a HTTP Action to “List campaigns” REST API endpoint and check if there are any campaigns assigned to the terminatedManager and state eq “pending”. If yes, the results as pendingCerts. You can store the IDs of such campaigns to be used in next step 5. - Loop Through Certifications:
Insert a Loop action using pendingCerts as input to process each pending certification individually by using “Get Certification Campaign” action. - Reassign Ownership:
Inside the loop, add another REST API Call(PATCH/PUT) action pointing at Reassign certifications API endpoint and pass the ID of the managerOfManager which we’ve obtained from step 3. This updates each certification from pendingCerts to assign ownership to the manager’s manager. - Send Notification (Optional):
Finally, use a Send Email action to notify the new owner that the certifications have been reassigned to them.
Also, after step 4, if the response doesn’t have any pending certs on the terminatedManager, you can exit the workflow to a end step directly.
Thanks,
Arshad.