Hi Team,
We do not have direct connector to Keeper and access to Keeper application is managed via Azure AD groups.
Group is revoked as part of UAR or user termination to remove the user’s access to Keeper.
The ask here is to send an email notification to Keeper’s team somehow about removal so that they can do some clean up from their end and create and manage SNOW ticket.
Thanks
Kalyan
Hi @kalyannambi2010 ,
Since Keeper is managed through Azure AD groups and there is no direct Keeper connector, I would handle this through an ISC Workflow.
You can trigger the workflow based on the provisioning event and filter for the specific Azure AD source/group removal, for example when the Keeper-related group is removed as part of UAR or termination.
The workflow can then:
Detect the removal of the Keeper Azure AD group.
Create a ServiceNow ticket using the Manage ServiceNow Ticket action (or an HTTP Request if you need a custom ServiceNow API).
Include useful details such as user identity, removed group, request/termination context, and any other information required by the Keeper team.
Send an email notification to the Keeper support/team with the ServiceNow ticket number.
Optionally monitor the ServiceNow ticket and send a follow-up notification when the ticket is completed.
Using the Manage ServiceNow Ticket action is preferable if you want ISC to maintain/manage the ticket lifecycle. SailPoint’s workflow approach also provides more flexibility for filtering specific identities, sources, and provisioning scenarios compared with the standard ServiceNow Service Desk integration.
The important part would be getting the provisioning-event payload first and confirming the exact JSON attributes exposed for the Azure AD group removal. Once that is confirmed, the workflow filter can be built specifically for the Keeper group rather than creating a ticket for every Azure AD group removal. Please refer below thread for reference.
If you don’t have SDIM available, the same approach can be implemented through Workflow + ServiceNow API/Service Catalog API, although ticket-status tracking requires some additional workflow logic.
Hope this helps.
Hi @suraj_gorle, thank you for the update but we stuck in managing the SNOW ticket and as of now implemented below workflow logic and could you please check and update and provide your feedback on the same?
new 535.json (4.3 KB)
What error you are facing? can you please give screenshot of error or error detail ?
Hi @suraj_gorle we did not yet configure the attached workflow in ISC but from use case point of view would like to know whether the attached workflow can create SNOW ticket and progress SNOW ticket as well till closure?
Thanks
Hi Kalyana. Yes, this can be designed in ISC, but the attached workflow as it stands will only create the ServiceNow incident. After the HTTP POST, it goes directly to Success, so it will not currently monitor or progress the ticket through closure.
I would suggest changing the flow to something like:
Provisioning Completed → Create SNOW Ticket → Send Email → Wait → Get Ticket Status → Compare Status
If the Keeper team is responsible for working and closing the ticket, ISC can periodically check the ticket status and continue once it is closed.
If ISC itself also needs to change the ticket status during the process, you can add Update ticket status at the required stages.
The Manage ServiceNow Ticket workflow action supports Create new ticket, Get ticket status, and Update ticket status, so I would use that instead of building all of the ServiceNow handling through HTTP unless you need custom API behavior.
Also, create the ticket before sending the email if you want the notification to include the ServiceNow ticket number.
Hi @punna0001 thank you for your reply and could you please check the attached workflow JSON and provide your feedback on the same and updated based on your feedback?
Keeper Security Revocation - Create, Notify, Wait & Verify Status_Test.json (10.0 KB)
Thanks
Hello Kalyana. Thanks for sharing the updated JSON. It is closer, but I would make a few changes before enabling it. The main issue is that the workflow checks the ServiceNow ticket only once. If it is not resolved or closed, it sends the follow-up email and goes to Success.
I would use a Serial Loop → While Loop:
Wait → Get Ticket Status → Compare Status → Break Loop when resolved/closed
Set a retry/SLA limit, then do one final Get Ticket Status → Compare Status outside the loop. If closed, send the completion email; otherwise send the escalation email.
I would also verify during testing:
state or incident_state carries your Resolved/Closed values.response.body.result...; confirm the actual output from execution historycaller_id, since the JSON passes an email into a ServiceNow reference fieldFinally, run one real Keeper revoke and confirm the Provisioning Completed payload matches the trigger filter.
HI Kalyan,
This can be achieved via workflow simply with the Action-> manage SNOW ticket then you can the status code for the ticket creation with the operator if its 201 then use Action-> Send Email to the keepers accordingly.
Hi @punna0001 thank you for the feedback. Could you please update the changes in the workflow JSON and attach here?
Thanks
Hi @Deepak_Chaudhary thank you for the feedback. Could you please update the workflow JSON and attach here?
Thanks
Hi Kalyana,
What will be your trigger in that case please provide the same will provide the json accordingly.
Thanks
Hi @kalyannambi2010 ,
you can use the below json and change according to your requirements.
"name": "SNOW Ticket",
"description": "When department changes",
"definition": {
"start": "Get Identity",
"steps": {
"Compare Numbers 1": {
"actionId": "sp:compare-numbers",
"choiceList": [
{
"comparator": "NumericEquals",
"nextStep": "Manage ServiceNow Ticket 1",
"variableA.$": "$.manageServiceNowTicket.statusCode",
"variableB": 201
}
],
"defaultStep": "End Step - Failure 1",
"displayName": "Compare Req api",
"type": "choice"
},
"Compare Numbers 2": {
"actionId": "sp:compare-numbers",
"choiceList": [
{
"comparator": "NumericEquals",
"nextStep": "Send Email",
"variableA.$": "$.manageServiceNowTicket.statusCode",
"variableB": 201
}
],
"defaultStep": "End Step - Failure 2",
"displayName": "compare item api",
"type": "choice"
},
"End Step - Failure 1": {
"actionId": "sp:operator-failure",
"displayName": "",
"failureName": "ServiceNow Request not created",
"type": "failure"
},
"End Step - Failure 2": {
"actionId": "sp:operator-failure",
"displayName": "",
"failureName": "ServiceNow Task not created",
"type": "failure"
},
"End Step — Success": {
"actionId": "sp:operator-success",
"description": "Request Success",
"displayName": "",
"type": "success"
},
"Get Access": {
"actionId": "sp:access:get",
"attributes": {
"accessprofiles": false,
"entitlements": true,
"getAccessBy": "searchQuery",
"identityToReturn.$": "$.getIdentity.id",
"query": "source.name:\"<SourceName>\"",
"roles": false
},
"description": null,
"displayName": "",
"nextStep": "Get Identity 1",
"type": "action",
"versionNumber": 1
},
"Get Identity": {
"actionId": "sp:get-identity",
"attributes": {
"id.$": "$.trigger.identity.id"
},
"displayName": "",
"nextStep": "Get Access",
"type": "action",
"versionNumber": 2
},
"Get Identity 1": {
"actionId": "sp:get-identity",
"attributes": {
"id.$": "$.getIdentity.managerRef.id"
},
"displayName": "Get Identity's manager",
"nextStep": "Manage ServiceNow Ticket",
"type": "action",
"versionNumber": 2
},
"Manage ServiceNow Ticket": {
"actionId": "sp:snow",
"attributes": {
"action": "create",
"authenticationType": "basic",
"basicAuthPassword": "$.secrets.*******",
"basicAuthUserName": "ServiceAccount",
"caller": "SailPoint Integration",
"category": null,
"customFields": "requested_for:{{$.getIdentity.attributes.email}}",
"description": "",
"oAuthClientId": null,
"oAuthTokenUrl": null,
"shortDescription": "shortDescription",
"urgency": "2",
"url": "https://abcde.service-now.com/api/now/v1/table/sc_request",
"watchlist": ""
},
"description": "Create Service Now Ticket",
"displayName": "Manage ServiceNow Ticket",
"nextStep": "Compare Numbers 1",
"type": "action",
"versionNumber": 1
},
"description": null,
"displayName": "",
"nextStep": "End Step — Success",
"type": "action",
"versionNumber": 2
}
}
},
"creator": {
"type": "IDENTITY",
"id": "********",
"name": "Name"
},
"trigger": {
"type": "EVENT",
"attributes": {
"attributeToFilter": "department",
"description": "Trigger on Department unit change",
"filter.$": "$.changes[?(@.attribute == \"department\")]",
"id": "idn:identity-attributes-changed",
"integrationId": null
}
}
Hi @punna0001 thank you for the feedback and could you please check the latest updated workflow JSON and provide your feedback on the same?
Thanks
Keeper Security Revocation - Manage SNOW Ticket Lifecycle_Test.json (12.4 KB)
Hello Kalyana. It is closer, but I would correct a few items before enabling it.
The main issue is the retry logic. It manually loops back to the Wait step, and the counter keeps referencing the original 0, so the retry limit will not work correctly. I would rebuild this using:
Serial While Loop → Wait → Get Ticket Status → Compare Status → Break Loop when resolved/closed
Also, rebuild Get ticket status in Workflow Builder and pass the Ticket ID from the Create ticket response instead of embedding the sys_id in the URL.
A few other checks:
state or incident_state for Resolved/Closed.Workflow Failure End is currently "type": "success".The .body.result... references and the updated email wording look good.
Hi @punna0001 thank you for the feedback and could you please check the latest updated workflow JSON and provide your feedback on the same?
Keeper Security Revocation - Manage SNOW Ticket Lifecycle_4.json (12.8 KB)
Two main items still need correction. The retry section is still using the manual counter/back-to-Wait logic rather than the native Serial Loop → While Loop. The counter also keeps referencing the initial value, so the retry limit will not work as intended. I would rebuild this section in Workflow Builder using While Loop + Break Loop.
The ServiceNow output paths also need correction. The native action returns the incident under body.result. For example:
$.createServiceNowIncidentTicket.body.result.task_effective_number$.createServiceNowIncidentTicket.body.result.sys_idUse the Ticket ID in Get ticket status rather than .ticketId/.ticketNumber.
Also, SailPoint documents Caller as the ServiceNow username, so confirm the email value you are passing matches that username.
The Failure end is fixed in this version. I would still test one real Keeper revoke before enabling it, especially since the workflow still references accountRequests[0].attributeRequests[0].
You can handle this use case through SailPoint ISC Workflow. Trigger your custom workflow on provisioning event and call the action step whichever is required as per your use case/requirement.
Hi @punna0001 could you please check the latest updated workflow JSON and provide your feedback on the same and make the changes?
Thanks
Keeper Security Revocation - Manage SNOW Ticket Lifecycle_Test1.json (13.2 KB)
Hi @punna0001 did you get a chance to look at the updated workflow JSON and provide your feedback on the same and make the changes?
Thanks
Keeper Security Revocation - Manage SNOW Ticket Lifecycle_Test1.json (13.2 KB)