...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
.
API Call and User Creation: Utilizing the parameters obtained from the request form, the workflow calls the EmpowerID API to create a new user account. The specifics of this API call, including the necessary parameters and the API endpoint, are detailed in this document's "Integrations" section.
Completion of the Workflow: Once the API call is successfully made and the new user account is created, the workflow updates the status of the request to "Closed Complete," signaling the end of the process.
EID – Add User to Group
This workflow is built to add users to a group within EmpowerID. When a request is submitted using this workflow, it runs a script block named “Subflow variable mapping”. This is an important step in case we want to use the EmpowerID workflow as a subflow in an existing customer workflow. The second step is the Approval activity, which is currently approved by the system administrator. Once approved (if rejected, the workflow sets the state of the request as “closed incomplete” and ends here), the workflow continues to the third step, which is where the actual API call to EmpowerID is made with all required parameters. Please refer to this article's Integrations section to know the API's details. After a successful call, the workflow marks the state of the RITM as “Closed Complete” and ends.
...
EID – Request Management Role
This workflow is built to associate a management role to a user within EmpowerID for a specified duration of time. At the very beginning, the workflow runs a script block that deals with variable mapping in the case when this workflow is being used as a subflow. The second step is the approval activity, which is currently approved by the system administrator. Once approved (if rejected, the workflow sets the state of the request as “closed incomplete” and ends here), the workflow continues to the third step, which is where the actual API call to EmpowerID is made with all required parameters. Please refer to this document's Integrations section to know more about the API's details. After the successful call, workflow marks the state of the RITM as “Closed Complete” and ends.
...
Data Model
The Orchestration Pack data model includes custom Groups and Management Roles data required for the EmpowerID workflows. In order to keep customer namespace uncluttered, EmpowerID does not use the default out-of-the-box tables for groups and roles, as many EmpowerID-specific attributes need to be maintained. The data for these custom tables is updated by EmpowerID via inbound API.
Tables
...
Groups (x_36687_eid_groups)
...
Management Roles (x_36687_eid_management_roles)
...
Column Label
...
Column Name
...
Type
...
Column Label
...
Column Name
...
Type
...
Group GUID (PK)
...
group_guid
...
String
...
Management Role GUID (PK)
...
management_role_guid
...
String
...
Name
...
name
...
String
...
Name
...
name
...
String
...
Distinguished Name
...
distinguished_name
...
String
The "EID – Add User to Group" workflow facilitates adding users to specific groups within EmpowerID, enhancing group management and access control. This workflow interfaces directly with EmpowerID's API, allowing for seamless integration and execution of group membership changes. Below is a step-by-step explanation of the workflow:
Subflow Variable Mapping: Initially, when a request is submitted, the workflow executes a script block titled “Subflow variable mapping.” This step is critical, especially if the workflow is intended as a subflow within an existing customer workflow. It ensures that all variables and parameters from the main flow are accurately mapped and available for the subflow, maintaining consistency and accuracy in data handling.
Approval Process: The subsequent step involves an approval activity, typically overseen by the system administrator. This step validates the request before proceeding with modifications to user group assignments.
If Approved: The workflow moves to the next stage, proceeding with the necessary API call to EmpowerID.
If Rejected: If the approval is not granted, the workflow marks the request as “Closed Incomplete,” and the process is terminated immediately. This ensures that no unauthorized changes are made.
API Integration and Execution: Upon receiving approval, the workflow executes an API call to EmpowerID. This call is crafted with all the required parameters directly submitted with the request or derived from the initial script block. The specifics of this API call, such as the endpoint and the parameters needed, are detailed in the "Integrations" section of the accompanying documentation.
Workflow Completion: Following a successful API call that adds the user to the designated group, the workflow updates the status of the Request Item (RITM) to “Closed Complete.” At this point, the process concludes, marking the successful addition of a user to a group.
EID – Request Management Role
The "EID – Request Management Role" workflow associates a management role with a user within EmpowerID for a designated period. This workflow ensures a streamlined role assignment process through several structured steps:
Initialization and Variable Mapping: At the beginning of the workflow, a script block is executed to handle variable mapping. This step is crucial, especially when the workflow is utilized as a subflow within another process, as it ensures that all variables are accurately aligned for subsequent steps.
Approval Process: The next step involves the approval activity, typically managed by the system administrator. This step determines the continuation of the workflow:
If Approved: The workflow moves to the API interaction phase.
If Rejected: The workflow sets the request status to “Closed Incomplete” and ends the process immediately.
API Interaction: Following approval, the workflow executes an API call to EmpowerID, using all the required parameters to assign the specified management role to the user. Detailed parameters and configuration for this API call can be found in the document's Integrations section.
Completion of the Workflow: After the successful API call, the workflow updates the Request Item (RITM) status to “Closed Complete,” marking the successful conclusion of the process.
Example Flows
EmpowerID provides custom flows within the orchestration package to automate specific tasks within the ServiceNow platform. These flows offer functionalities similar to those covered in EmpowerID workflows. The flows can be seamlessly integrated into your existing processes or modified to meet your unique requirements.
EID – New Hire
This EID - New Hire is designed to create a new user using the EmpowerID APIs. The flow triggers the Admin Approval activity whenever a new hire request is submitted. This activity sends an approval request to the system administrator to decide on the approval process. If the admin rejects the request, it is marked as "closed incomplete," and the flow ends. Once the system admin approves the request, the flow proceeds, and the input parameters from the submitted request form are used to trigger the API call to EmpowerID. You can find more information about this API call in the Integrations section of this document. Once the API call is made successfully, the request is marked as "closed complete," and the flow ends.
EID – Add User to Group
This flow is designed to add users to a group in EmpowerID. When a request is submitted, the flow retrieves the catalog item variable. The next step is the Approval activity, which the manager currently approves. Once approved, the flow moves to the third step, where an API call to EmpowerID is made with all required parameters. The details of the API can be found in the Integrations section of this article. If the request is rejected, the flow sets the state of the request as “closed incomplete” and stops. After a successful call, the flow marks the state of the RITM as “Closed Complete” and ends.
EID – Request Management Role
This flow is designed to assign a management role to a user in EmpowerID for a specific period of time. Initially, the flow retrieves the catalog variables from EID by requesting the management role. The second step involves an approval activity, which is approved by the approver designated to the management role or the default approver. If the request is rejected, the flow will set the request's state to "closed incomplete" and end. After approval, the flow proceeds to the third step, where the necessary parameters are used to make an API call to EmpowerID. For more information on the API's specifics, please refer to the Integrations section of this document. The flow marks the RITM's state as "Closed Complete" upon a successful call and ends.
Data Model
The Orchestration Pack data model includes custom Groups and Management Roles data required for the EmpowerID workflows. To keep the customer namespace uncluttered, EmpowerID does not use the default out-of-the-box tables for groups and roles, as many EmpowerID-specific attributes need to be maintained. EmpowerID updates the data for these custom tables via inbound API.
Tables
Groups (x_36687_eid_groups) | Management Roles (x_36687_eid_management_roles) | ||||
|---|---|---|---|---|---|
Column Label | Column Name | Type | Column Label | Column Name | Type |
Group GUID (PK) | group_guid | String | Management Role GUID (PK) | management_role_guid | String |
Name | name | String | Name | name | String |
Distinguished Name | distinguished_name | String | Friendly Name | friendly_name | String |
Is High Security Group | is_high_security_goup | Boolean | String | ||
Auto Accept Join Leave Request | auto_accept_join_leave_requests | Boolean | Is High Security | is_high_security | Boolean |
Group Usage Type Friendly Name | group_usage_type_friendly_name | String | Auto Accept Join Leave Request | auto_accept_join_leave_requests | Boolean |
Friendly Name | friendly_name | String | Requestable | requestable | Boolean |
Logon Name | logon_name | String | Risk Factor Total | risk_factor_total | Integer |
Account Store Friendly Name | account_store_friendly_name | String | Valid From | valid_from | Date/Time |
Allow Join Requests | allow_join_requests | Boolean | Valid Until | valid_until | Date/Time |
String | Description | description | String | ||
Valid From | valid_from | Date/Time | Instructions | instructions | String |
Valid Until | valid_until | Date/Time | Owner Assignee ID | owner_assignee_id | String |
Description | description | String | Owner Login Name | owner_login_name | String |
Notes | notes | String | Owner Friendly Name | owner_friendly_name | String |
Owner Assignee ID | owner_assignee_id | String | Owner Email | owner_email | String |
Owner Login Name | owner_login_name | String | Extension Attribute 1 | extension_attribute_1 | String |
Owner Friendly Name | owner_friendly_name | String | Extension Attribute 2 | extension_atrtibute_2 | String |
Owner Email | owner_email | String | Extension Attribute 3 | extension_attribute_3 | String |
Extension Attribute 1 | extension_attribute_1 | String | Extension Attribute 4 | extension_attribute_4 | String |
Extension Attribute 2 | extension_attribute_2 | String | Extension Attribute 5 | extension_attribute_5 | String |
Extension Attribute 3 | extension_attribute_3 | String | Extension Attribute 6 | extension_attribute_6 | String |
Extension Attribute 4 | extension_attribute_4 | String | Extension Attribute 7 | extension_attribute_7 | String |
Extension Attribute 5 | extension_attribute_5 | String | Extension Attribute 8 | extension_attribute_8 | String |
Extension Attribute 6 | extension_attribute_6 | String | Extension Attribute 9 | extension_attribute_9 | String |
Extension Attribute 7 | extension_attribute_7 | String | Extension Attribute 10 | extension_attribute_10 | String |
Extension Attribute 8 | extension_attribute_8 | String | Extension Attribute 11 | extension_attribute_11 | String |
Extension Attribute 9 | extension_attribute_9 | String | Extension Attribute 12 | extension_attribute_12 | String |
Extension Attribute 10 | extension_attribute_10 | String | Extension Attribute 13 | extension_attribute_13 | String |
Extension Attribute 11 | extension_attribute_11 | String | Extension Attribute 14 | extension_attribute_14 | String |
Extension Attribute 12 | extension_attribute_12 | String | Extension Attribute 15 | extension_attribute_15 | String |
Extension Attribute 13 | extension_attribute_13 | String | Sys ID | sys_id | Sys ID (GUID) |
Extension Attribute 14 | extension_attribute_14 | String | Updates | sys_mod_count | Integer |
Extension Attribute 15 | extension_attribute_15 | String | Updated By | sys_updated_by | String |
Sys ID | sys_id | Sys ID (GUID) | Updated | sys_updated_by | String |
Updates | sys_mod_count | Integer | |||
Updated By | sys_updated_by | String | |||
Updated | sys_updated_by | String | |||
| Insert excerpt | ||||||
|---|---|---|---|---|---|---|
|
| Anchor | ||||
|---|---|---|---|---|
|
The EmpowerID Orchestration Pack has
...
...
...
...
Boolean
...
Yes
...
risk_factor_total
...
Risk factor of the role
...
...
...
...
...
...
...
...
...
...
...
...
...
Yes
...
extension_attribute_12
...
Extension attribute
...
String
...
Yes
...
extension_attribute_13
...
Extension attribute
...
String
...
Yes
...
extension_attribute_14
...
Extension attribute
...
String
...
Yes
...
extension_attribute_15
...
Extension attribute
...
String
...
Yes
Create Management Groups
MgmtGroups
This endpoint is used to create / push Management Groups from EmpowerID to ServiceNow
HTTP Request
Method: POST
| Code Block |
|---|
POST https://{FQDN_Of_Your_ServiceNow_Instance}/api/x_36687_eid/eid/mgmtgroups |
Request Data
Request data is sent to the API in JSON format.
...
...
...
...
...
...
...
...
...
...
...
Element
...
Description
...
Type
...
Required
...
group_guid
...
GUID of the group
...
String
...
Yes
...
friendly_name
...
...
distinguished_name
...
...
...
...
Distinguished name of the account store the group belongs to
...
...
...
...
...
...
...
Ending date and time the group is valid
...
Date/Time
...
Yes
...
description
...
...
...
...
Can users request to join the group?
...
...
...
Accept join and leave requests without requiring approval
...
Boolean
...
Yes
...
...
...
notes
...
...
...
Is the group high security?
...
...
...
...
ID of the EmpowerID Person owning the group
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
Extension attribute
...
String
...
Yes
...
extension_attribute_7
...
Extension attribute
...
String
...
Yes
...
extension_attribute_8
...
Extension attribute
...
String
...
Yes
...
extension_attribute_9
...
Extension attribute
...
String
...
Yes
...
extension_attribute_10
...
Extension attribute
...
String
...
Yes
...
extension_attribute_11
...
Extension attribute
...
String
...
Yes
...
extension_attribute_12
...
Extension attribute
...
String
...
Yes
...
extension_attribute_13
...
Extension attribute
...
String
...
Yes
...
extension_attribute_14
...
Extension attribute
...
String
...
Yes
...
extension_attribute_15
...
Extension attribute
...
String
...
Yes
Delete Management Roles
...
...
...
...
Delete Management Groups
deleteMgmtGroups
Use this endpoint to delete EmpowerID Groups currently present in ServiceNow.
HTTP Request
Method: POST
...
...
...
...
Header Key/Value Pairs
...
Key
...
Value
...
X-UserToken
...
Your access token
...
Accept
...
application/json
...
Content-Type
...
application/json
Response
...
...
Content-Encoding
...
gzip
...
Date
...
Date / Time GMT
...
Server
...
ServiceNow
...
Strict-Transport-Security
...
max-age63072000; includeSubDomains
...
Transfer-Encoding
...
chunked
...
X-Is-Logged-In
...
true
...
X-Transaction-Id
...
85d3c5addb2u8
...
curl "https://YourServiceNowInstance/api/x_36687_eid/eid/deleteMgmtGroups" \
--request POST \
--header "Accept:application/json" \
--user 'admin':'admin'...
| title | EmpowerID APIs Consumed by ServiceNow |
|---|
There are 3 main tasks performed in EmpowerID workflows within ServiceNow that are accomplished by making an API call to EmpowerID application. These tasks are as below:
Create Employee
Assign Group
Assign Management Role
To invoke the above API calls, the identity making the call must have a valid token. For information on getting a token, see Getting an Access Token.
Create Employee
HTTP Method: POST
Endpoint
| Code Block |
|---|
https://{FQDN_OF_Your_EmpowerID_Web_Server}/api/services/v1/ExecuteWorkflow/start |
Header Key/Value Pairs
...
Key
...
Value
...
Authorization
...
Bearer ${token}
...
X-EmpowerID-API-Key
...
f0f46cce-7cd1-4c34-8f7e-d54e96a2ab41
...
Content-Type
...
application/json
Request Data
Request data is sent to the API in JSON format.
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...