EPM - ServiceNow integration | EPM-WM
Important informationYou must purchase this integration separately for both your EPM-WM software and your ServiceNow solution. For more information, contact BeyondTrust's Sales team.
The BeyondTrust Endpoint Privilege Management for Cloud (EPM) - ServiceNow integration allows organizations to streamline their Just-In-Time (JIT) access approval workflow. This integration automatically creates ServiceNow tickets when EPM JIT access requests are submitted and enables approvers to make decisions directly from within ServiceNow.
This new version of EPM - ServiceNow integration supports Admin Access requests and introduces a redesigned ServiceNow app architecture that makes it easier for you to customize the experience to fit your workflows.
You can continue using the existing integration but we do provide migration steps in this topic.
Key features
-
Automated ticket creation: Automatically creates ServiceNow tickets when JIT Application Access or Admin Access requests are submitted in EPM
-
Dual request type support: Manages both Application Access requests and Admin Access (privilege elevation) requests
-
Flexible ticket type support: Works out of the box with Incident, Change Request, Service Catalog Task, and Service Catalog Requested Item ticket types. Can be customized to support any Task-based ticket type.
-
Customizable workflow: Built using ServiceNow Flow Designer, allowing administrators to customize the integration workflow to match organizational requirements and processes
-
Integrated approval workflow: Approve or deny requests directly from ServiceNow tickets with custom UI actions
-
Real-time synchronization: Status updates are synchronized between EPM and ServiceNow
-
Comprehensive request details: All relevant request information is captured in the ServiceNow ticket
-
Configurable duration control: Set time-limited access approvals with granular duration options
-
Automatic ticket closure: Optionally configure the integration to automatically close tickets after a decision has been submitted and processed
Architecture
The integration is implemented as a ServiceNow scoped application that:
- Receives webhook messages from EPM when JIT Application Access or Admin Access tickets are created or updated
- Creates corresponding ServiceNow tickets with all relevant request information in your chosen ticket type
- Provides custom UI actions and forms within ServiceNow for approving/denying requests
- Communicates decisions back to EPM via the management API
- Processes status updates from EPM when decisions are finalized
Prerequisites
Before installing and configuring the integration, ensure you have:
-
BeyondTrust EPM: A currently supported version of BeyondTrust Endpoint Privilege Management
-
ServiceNow: The application is certified for compatibility with supported ServiceNow versions (check the ServiceNow Store listing for specific version compatibility)
-
ServiceNow Administrator access with rights to:
- Install applications from the ServiceNow Store
- Create user accounts and assign roles
- Configure application settings
- Create and manage tickets in your chosen ticket type
-
EPM Administrator access to:
- Configure API Settings
- Configure JIT Access Settings
- Configure Webhook Settings
Legacy app: compatibility and migration
If you are currently using the legacy BeyondTrust Endpoint Privilege Management Integration application for ServiceNow, this section provides important information about migrating to the new application.
Side-by-side compatibility
The new application (BeyondTrust Privilege Management) and the legacy application can coexist in the same ServiceNow instance:
-
No Uninstallation Required: You do not need to uninstall the legacy application before installing the new application
-
Independent Operation: Both applications operate independently and do not interfere with each other
-
Separate Scopes: The applications use different scoped namespaces:
- Legacy application:
x_bmgr_pmc - New application:
x_bets_pmc_jit
- Legacy application:
Data retention
If you have historical JIT access request data from the legacy application:
-
Keep Legacy App Installed: The legacy application stores request data in custom tables. To maintain access to this historical data, leave the legacy application installed in your ServiceNow instance.
-
Data Migration Not Required: Historical data does not need to be migrated to the new application. The new application will create its own records going forward.
-
Reporting Considerations: If you have reports or dashboards based on legacy application tables, they will continue to function as long as the legacy application remains installed.
Migration
The migration from the legacy application to the new application is straightforward:
Step 1: Install new application
-
Install the new BeyondTrust Privilege Management application from the ServiceNow Store (see Installation Steps)
-
Complete the configuration steps in the new application (see Configuration)
-
Test the new application to ensure it is functioning correctly
Step 2: Update EPM configuration
The "cut-over" from the legacy application to the new application is a simple configuration change in EPM:
-
Navigate to: EPM → Configuration → Just-in-Time (JIT) Access Settings
-
Under Application Access:
- In the Choose an Integration dropdown, change from ServiceNow to EPM
- Click Save Changes
-
If using Admin Access, under Admin Access:
- Enable JIT Admin Access Integration (if not already enabled)
- Click Save Changes
-
Configure webhooks in EPM as described in the Configure Webhook Settings section
That's it! New JIT access requests will now be sent to the new application via webhooks instead of the legacy application.
Step 3: (Optional) Monitor both applications
During the migration period:
-
New Requests: All new JIT access requests will be created in the new application
-
Pending Legacy Requests: Any requests that were pending in the legacy application before the cut-over can still be managed through the legacy application
-
Seamless Continuity: Users can continue to approve or deny legacy requests without interruption, ensuring no requests are lost during the migration
Managing legacy requests after migration
Even after switching to the new application in EPM, you can still manage pending requests from the legacy application:
-
Access legacy tickets: Navigate to the ticket type used by the legacy application (Incident, Change Request, etc.) and open any pending JIT access requests
-
Approval actions available: The legacy application's approval UI actions will continue to function as long as the application is installed
-
Decision submission: Approved or denied decisions will be sent to EPM and processed normally
-
Historical Reference: Completed legacy requests remain accessible for audit, compliance, and reporting purposes
Post-Migration considerations
After successfully migrating to the new application:
When to uninstall legacy application
You may consider uninstalling the legacy application when:
- All pending legacy requests have been completed (approved, denied, or closed)
- You no longer need access to historical legacy request data
- You have exported or archived any legacy data needed for compliance or reporting
Important informationOnce the legacy application is uninstalled, you can no longer access the historical JIT request data it created.
Best practices
-
Test thoroughly: Test the new application in a development or test environment before migrating in production
-
Communication: Inform help desk staff and approvers about the migration timeline and any workflow changes
-
Monitoring: Monitor both applications during the transition period to ensure smooth operation
-
Documentation: Update internal documentation and procedures to reflect the new application
-
Training: Provide training to staff on any differences between the legacy and new applications (e.g., new UI, additional features like Admin Access support)
Key differences between legacy and new application
Understanding the differences can help with planning and training:
| Feature | Legacy Application | New Application |
|---|---|---|
| Integration method | Polling/API calls | Webhook-based |
| Request types | Application Access only | Application Access and Admin Access |
| EPM configuration | ServiceNow selection | EPM selection + webhooks |
| Workflow engine | Server-side scripts | Flow designer (customizable) |
| Ticket types | Fixed configuration | Flexible, customizable |
| Auto-close | Not available | Optional configuration |
Migration support
If you need assistance with the migration:
- Review this guide thoroughly before beginning
- Test in a non-production environment first
- Contact BeyondTrust Support if you encounter issues:
- Email: [email protected]
- Hours: US Central Time, Monday-Friday, 2:00 AM - 7:00 PM (excluding US holidays)
Installation steps
Step 1: Install the ServiceNow application
-
Navigate to the ServiceNow Store
-
Search for "BeyondTrust Privilege Management"
-
Click Get or Install and follow the prompts to install the application into your ServiceNow instance
-
Wait for the installation to complete
-
Verify the application appears in your ServiceNow navigator under BeyondTrust Privilege Management
Step 2: Create webhook user account
A dedicated user account is required for EPM webhooks to authenticate to ServiceNow.
-
Navigate to User Administration → Users
-
Click New to create a new user
-
Configure the user with the following settings:
- User ID:
pmc_webhook_user(or your preferred username) - First name: PMC
- Last name: Webhook User
- Email: (optional)
- Identity Type: Machine (Yokohama patch 6 or later)
- Web service access only: ✅ Check this box (Yokohama patch 5 or earlier ... see KB2420837 for more information)
- Active: ✅ Ensure this is checked
- User ID:
-
Click Submit to save the user
-
Reopen the user record and click Set Password
-
Generate or enter a strong password and record it securely for use in EPM webhook configuration
-
Click the Roles tab, then click Edit
-
Add the role x_bets_pmc_jit.api to the user
-
Click Save
This role grants the necessary permissions to create and update tickets via the webhook API endpoint.
Configuration
Configure EPM
1. Configure API Settings
The API account is used by ServiceNow to communicate decisions back to EPM.
-
Navigate to: EPM → Configuration → API Settings
-
Click Create API Account
-
Configure the API account with the following settings:
- Name: ServiceNow Integration
- Permissions:
- JIT: Full Access
-
Click Save
-
Important: Copy and securely store the Client ID and Client Secret values. You will need these when configuring the ServiceNow application.
Security noteThe Client Secret is only displayed once. Ensure you save it securely before leaving this page.
2. Configure JIT Access Settings
Enable the JIT access integrations that you want to use with ServiceNow.
-
Navigate to: EPM → Configuration → Just-in-Time (JIT) Access Settings
-
Under Application Access, configure the following:
- ✅ Enable JIT Application Access Integration
- Choose an Integration: Select EPM
- Click Save Changes
-
Under Admin Access, configure the following:
- ✅ Enable JIT Admin Access Integration
- Click Save Changes
Note: You can enable one or both integration types depending on your requirements. If you only enable one type, you will only need to create two webhooks (create and update) instead of four.
3. Configure webhook settings
You will create webhooks for each event type you want to integrate with ServiceNow.
Webhook URL
The webhook URL for all webhooks will follow this pattern:
https://YOUR-INSTANCE.service-now.com/api/x_bets_pmc_jit/authorization_request_webhook_handler
Replace YOUR-INSTANCE with your actual ServiceNow instance subdomain.
Example: https://acme.service-now.com/api/x_bets_pmc_jit/authorization_request_webhook_handler
Create webhooks
-
Navigate to: EPM → Configuration → Webhook Settings
-
Click Create Webhook
Webhook 1: JIT Admin Ticket Created
Configure the first webhook with the following settings:
- Name: ServiceNow - Admin Access - Create
- URL:
https://YOUR-INSTANCE.service-now.com/api/x_bets_pmc_jit/authorization_request_webhook_handler - Event: JIT Admin Ticket Created
- Content Type:
application/json - Template: Use the template below
- Authentication Type: Basic
- Authentication Username:
pmc_webhook_user(or the username you created) - Authentication Password: The password you set for the webhook user
- Enable Webhook: ✅ Check to enable
Template for JIT Admin Ticket Created:
{
"EventType": "JIT_ADMIN_TICKET_CREATED",
"RequestId": "%%RequestId%%",
"TenantId": "%%TenantId%%",
"Timestamp": "%%Timestamp%%",
"ComputerId": "%%ComputerId%%",
"GroupId": "%%GroupId%%",
"TicketNumber": "%%TicketNumber%%",
"Reason": "%%Reason%%",
"UserId": "%%UserId%%",
"UserName": "%%UserName%%",
"DurationRequested": "%%DurationRequested%%"
}Click Save.
Webhook 2: JIT Admin Decision Updated
Create a second webhook with the following settings:
- Name: ServiceNow - Admin Access - Update
- URL:
https://YOUR-INSTANCE.service-now.com/api/x_bets_pmc_jit/authorization_request_webhook_handler - Event: JIT Admin Decision Updated
- Content Type:
application/json - Template: Use the template below
- Authentication Type: Basic
- Authentication Username:
pmc_webhook_user - Authentication Password: The password you set for the webhook user
- Enable Webhook: ✅ Check to enable
Template for JIT Admin Decision Updated:
{
"EventType": "JIT_ADMIN_TICKET_UPDATED",
"RequestId": "%%RequestId%%",
"TicketNumber": "%%TicketNumber%%",
"TenantId": "%%TenantId%%",
"StartTime": "%%StartTime%%",
"EndTime": "%%EndTime%%",
"Decision": "%%Decision%%",
"DecisionTime": "%%DecisionTime%%",
"DecisionPerformedByUser": "%%DecisionPerformedByUser%%",
"Duration": "%%Duration%%",
"DurationRequested": "%%DurationRequested%%",
"Timestamp": "%%Timestamp%%"
}Click Save.
Webhook 3: JIT Application Access Ticket Created
Create a third webhook with the following settings:
- Name: ServiceNow - App Access - Create
- URL:
https://YOUR-INSTANCE.service-now.com/api/x_bets_pmc_jit/authorization_request_webhook_handler - Event: JIT Application Access Ticket Created
- Content Type:
application/json - Template: Use the template below
- Authentication Type: Basic
- Authentication Username:
pmc_webhook_user - Authentication Password: The password you set for the webhook user
- Enable Webhook: ✅ Check to enable
Template for JIT Application Access Ticket Created:
{
"EventType": "URM_Native_Ticket_Created",
"RequestId": "%%RequestId%%",
"TenantId": "%%TenantId%%",
"Timestamp": "%%Timestamp%%",
"TicketNumber": "%%TicketNumber%%",
"requestInfo": {
"applicationType": "%%ApplicationType%%",
"action": "%%Action%%",
"workstyle": "%%Workstyle%%",
"reason": "%%Reason%%",
"user": "%%User%%",
"hostName": "%%HostName%%",
"trustedOwnership": "%%trustedOwnership%%",
"productDescription": "%%ProductDescription%%",
"driveType": "%%DriveType%%",
"btZoneIdentifierExists": "%%BtZoneIdentifierExists%%",
"productCode": "%%ProductCode%%",
"upgradeCode": "%%UpgradeCode%%",
"clsId": "%%ClsId%%",
"comDisplayName": "%%ComDisplayName%%",
"token": "%%Token%%",
"tokenAssignmentIsShell": "%%TokenAssignmentIsShell%%",
"uacTriggered": "%%UacTriggered%%",
"downloadSourceUrl": "%%DownloadSourceUrl%%",
"userLanguage": "%%UserLanguage%%",
"sha1Hash": "%%Sha1Hash%%",
"sha256Hash": "%%Sha256Hash%%",
"filePathObjectId": "%%FilePathObjectId%%",
"cmdArgs": "%%CmdArgs%%",
"publisher": "%%Publisher%%",
"productName": "%%ProductName%%",
"productVersion": "%%ProductVersion%%",
"fileVersion": "%%FileVersion%%",
"workstyle": "%%Workstyle%%",
"applicationGroup": "%%ApplicationGroup%%",
"message": "%%Message%%",
"messageId": "%%MessageId%%",
"hostType": "%%HostType%%",
"osName": "%%OsName%%",
"osVersion": "%%OsVersion%%",
"ComputerGroup": "%%ComputerGroup%%",
"GroupId": "%%GroupId%%",
"requestVersion": "%%RequestVersion%%",
"hostedFilePath": "%%HostedFilePath%%",
"parentProcess": "%%ParentProcess%%",
"storeAppName": "%%StoreAppName%%",
"serviceName": "%%ServiceName%%",
"serviceAction": "%%ServiceAction%%",
"authRequestUri": "%%AuthRequestUri%%",
"bundleInfoDescription": "%%BundleInfoDescription%%",
"reputationScoreDateTime": "%%ReputationScoreDateTime%%",
"reputationScore": "%%ReputationScore%%",
"reputationIntegrationType": "%%ReputationIntegrationType%%"
}
}Click Save.
Webhook 4: JIT Application Access Decision Updated
Create a fourth webhook with the following settings:
- Name: ServiceNow - App Access - Update
- URL:
https://YOUR-INSTANCE.service-now.com/api/x_bets_pmc_jit/authorization_request_webhook_handler - Event: JIT Application Access Decision Updated
- Content Type:
application/json - Template: Use the template below
- Authentication Type: Basic
- Authentication Username:
pmc_webhook_user - Authentication Password: The password you set for the webhook user
- Enable Webhook: ✅ Check to enable
Template for JIT Application Access Decision Updated:
{
"EventType": "URM_NATIVE_DECISION_UPDATE",
"RequestId": "%%RequestId%%",
"TenantId": "%%TenantId%%",
"TicketNumber": "%%TicketNumber%%",
"Timestamp": "%%Timestamp%%",
"requestInfo": {
"Decision": "%%Decision%%",
"DecisionTime": "%%DecisionTime%%",
"DecisionPerformedByUser": "%%DecisionPerformedByUser%%",
"Duration": "%%Duration%%"
}
}Click Save.
Configure ServiceNow application
Configure the application settings
-
Navigate to BeyondTrust Privilege Management → Configuration
-
If you see multiple configuration records, select the one named Default
PM Cloud Instance Settings
Configure the connection to your EPM instance:
| Setting | Description | Example |
|---|---|---|
| PMC Service Host Name | The hostname of your EPM services endpoint. Use the format: subdomain-services.beyondtrustcloud.com | acme-services.beyondtrustcloud.com |
| PMC Tenant ID | (Optional) Your EPM tenant ID if required | |
| Client ID | The Client ID from the EPM API account created earlier | pmc-api-account-client-id |
| Client Secret | The Client Secret from the EPM API account | [secret-value] |
Important informationThe PMC Service Host Name must include the
-servicessuffix after your subdomain. For example, if your EPM URL ishttps://acme.beyondtrustcloud.com, your service hostname should beacme-services.beyondtrustcloud.com(without https://).
Ticket configuration settings
Configure how ServiceNow tickets are created and managed:
| Setting | Description | Example |
|---|---|---|
| Ticket Type | The type of ServiceNow ticket to create for JIT requests | Incident, Change Request, Service Catalog - Task, or Service Catalog - Requested Item |
| Active States | Comma-separated list of ticket states in which the integration actions are available to users | New, In Progress, On Hold |
| Default Short Description | Default summary text for created tickets | EPM JIT Access Request |
| Default Assignment Group | (Optional) Default group to assign tickets to | IT Security |
| Default Category | (Optional) Default category for tickets | Software |
| Attempt to Auto-Close Ticket After Decision Submitted | Automatically close the ServiceNow ticket when a decision is submitted | ✅ (Optional) |
Important information
Active States: Only tickets in these states will display the JIT access management UI actions. Ensure you include all states where you want users to be able to approve or deny requests.
Ticket Type: Once you begin using the integration, changing the ticket type may require additional configuration and can affect existing workflows.
- Click Update to save the configuration
Test the connection
Verify that ServiceNow can communicate with EPM:
-
Navigate to BeyondTrust Privilege Management → Test Connection
-
Click Test
-
You should see a success message: "Connection OK"
-
If you see an error:
- Verify the PMC Service Host Name is correct (including the
-servicessuffix) - Verify the Client ID and Client Secret are correct
- Check System Logs → Application Logs for detailed error messages
- Ensure your ServiceNow instance can reach the EPM services endpoint (check firewall/network rules)
- Verify the PMC Service Host Name is correct (including the
Assign user roles
The application includes roles that should be assigned to appropriate users in your ServiceNow instance.
Available roles
| Role | Purpose | Assign To |
|---|---|---|
| x_bets_pmc_jit.api | API access for webhook endpoint | Webhook service account only |
| x_bets_pmc_jit.admin | Full administrative access to the integration | ServiceNow administrators managing the integration |
| x_bets_pmc_jit.user | View and manage JIT access requests within tickets | Help desk staff, security team members who approve/deny requests |
Assign roles to users
-
Navigate to User Administration → Users
-
Select a user
-
Click the Roles tab
-
Click Edit
-
Add the appropriate role(s) from the Collection list:
- x_bets_pmc_jit.admin for administrators
- x_bets_pmc_jit.user for help desk staff
-
Click Save
Security noteDo not assign the
x_bets_pmc_jit.apirole to regular users. Only assign the role to the dedicated webhook service account.
User interface
ServiceNow ticket form
Once configured, when EPM sends a webhook for a new JIT access request, a ServiceNow ticket is automatically created in your configured ticket type.
Application Access request tickets
Application Access requests include detailed information about the application the user is trying to run:
Request information section:
- User requesting access
- Host name
- Application/file path
- Product name and version
- Publisher
- File hashes (SHA1, SHA256)
- Reason for access
- Command line arguments
- Workstyle and application group
- Additional technical details
Admin Access request tickets
Admin Access requests include information about the privilege elevation request:
Request information section:
- User requesting access (Username and User ID)
- Computer ID
- Group ID
- Duration requested
- Reason for access
- Request timestamp
- Ticket number from EPM
Approval UI actions
Users with the appropriate role will see UI actions on the ticket to manage the JIT access request.
Approve Application Access button
Clicking this button opens a dialog box to approve the application access request:
Decision form fields:
- Decision: Select "Approved"
- Reason: Enter a justification for the approval (required)
- Duration: Choose the access duration:
- Once: Single-use access (user can run the application one time)
- Minutes: Specify duration in minutes (5-1440 minutes, or up to 24 hours)
- Hours: Specify duration in hours (1-24 hours)
Deny Application Access button
Clicking this button opens a dialog box to deny the application access request:
Decision form fields:
- Decision: Select "Denied"
- Reason: Enter a justification for the denial (required)
Approve Admin Access button
Clicking this button opens a dialog to approve the admin access request:
Decision form fields:
- Decision: Select "Approved"
- Reason: Enter a justification for the approval (required)
- Duration: Choose the privilege elevation duration:
- Once: Single elevation (user can elevate once)
- Minutes: Specify duration in minutes (5-1440 minutes)
- Hours: Specify duration in hours (1-24 hours)
Deny Admin Access button
Clicking this button opens a dialog to deny the admin access request:
Decision form fields:
- Decision: Select "Denied"
- Reason: Enter a justification for the denial (required)
Decision validation
The application includes client-side and server-side validation:
- Reason Required: A reason must be provided for all decisions
- Duration Validation: Duration values must be within valid ranges
- State Validation: Decisions can only be made on tickets in configured active states
- One-Time Decision: Once a decision has been submitted and acknowledged by EPM, it cannot be changed
Workflow
1. Create a request
Application access workflow
-
User on a managed endpoint attempts to run an application that requires elevated privileges or matches a JIT policy
-
EPM generates a JIT Application Access request
-
EPM sends a webhook to ServiceNow with event type
URM_Native_Ticket_Created -
ServiceNow receives the webhook and creates an incoming request record
-
ServiceNow Flow processes the request and creates a ticket in the configured ticket type
-
The ticket is assigned based on the configured assignment group (if specified)
-
Approver is notified via standard ServiceNow notifications
Admin Access workflow
-
User on a managed endpoint requests administrative privilege elevation
-
EPM generates a JIT Admin Access request
-
EPM sends a webhook to ServiceNow with event type
JIT_ADMIN_TICKET_CREATED -
ServiceNow receives the webhook and creates an incoming request record
-
ServiceNow Flow processes the request and creates a ticket in the configured ticket type
-
The ticket is assigned based on the configured assignment group (if specified)
-
Approver is notified via standard ServiceNow notifications
2. Approval process
-
Approver opens the ServiceNow ticket
-
Reviews the request details in the ticket form
-
Clicks the appropriate UI action button:
- Approve Application Access or Approve Admin Access to grant access
- Deny Application Access or Deny Admin Access to reject access
-
Fills out the decision form:
- Selects decision (Approved/Denied)
- Enters a reason (required)
- If approved, specifies duration or selects "Once" for single-use access
-
Submits the decision
-
ServiceNow validates the decision and makes an API call to EPM
-
EPM processes the decision
-
The ticket form updates to show the decision has been submitted
3. Status updates
-
EPM finalizes the decision and applies it to the policy
-
EPM sends a webhook to ServiceNow with the update event:
URM_NATIVE_DECISION_UPDATEfor Application AccessJIT_ADMIN_TICKET_UPDATEDfor Admin Access
-
ServiceNow receives the update and records the decision timestamp
-
The ticket form displays the finalized decision information
-
If auto-close is enabled, ServiceNow closes the ticket
-
User receives access (if approved) based on the configured duration
4. Duration-based access
For approved requests with time-limited access:
-
Once: User can run the application or elevate privileges one time. The authorization expires after the first use.
-
Minutes/Hours: User has access for the specified duration. The authorization automatically expires when the time limit is reached.
After the duration expires:
- The user must submit a new request to regain access
- A new ticket will be created in ServiceNow
- The approval process starts over
Troubleshooting
Common issues
Missing configuration record
Symptoms:
- Error message "Record not found" when navigating to BeyondTrust Privilege Management → Configuration
- Unable to configure the application settings
- Integration appears installed but cannot be configured
Cause:
The default configuration record was not created automatically during installation, or it was accidentally deleted.
Solution:
-
Navigate to BeyondTrust Privilege Management → Create Default Configuration
-
Click Run Fix Script to generate the default configuration record
-
Wait for the confirmation message indicating the configuration was created successfully
-
Navigate back to BeyondTrust Privilege Management → Configuration
-
Verify you can now access the configuration record named Default
The Fix Script that creates the default configuration record normally runs automatically when the application is installed. This manual step is only necessary if the automatic creation failed or if the configuration record was deleted.
Webhooks not received
Symptoms:
- EPM sends webhooks but tickets are not created in ServiceNow
- No incoming request records in ServiceNow
Possible causes and solutions:
-
Webhook URL incorrect
- Verify the URL matches the pattern:
https://YOUR-INSTANCE.service-now.com/api/x_bets_pmc_jit/authorization_request_webhook_handler - Check for typos in the instance name
- Ensure there are no extra spaces or characters
- Verify the URL matches the pattern:
-
Authentication failure
- Verify the webhook user credentials are correct
- Confirm the user has the
x_bets_pmc_jit.apirole - Check that the user is active and not locked
-
Network connectivity
- Verify ServiceNow instance is accessible from EPM
- Check firewall rules allow inbound HTTPS traffic from EPM services
- Test connectivity from EPM to ServiceNow URL
-
Content-Type mismatch
- Ensure webhook Content-Type is set to
application/json
- Ensure webhook Content-Type is set to
Troubleshooting steps:
-
Check EPM webhook delivery logs for errors
-
Navigate to BeyondTrust Privilege Management → Incoming Requests to see if webhooks are being received
-
Check System Logs → Application Logs filtered by source
x_bets_pmc_jitfor error messages -
Use ServiceNow's REST API Explorer to test the webhook endpoint manually
Tickets not created
Symptoms:
- Incoming requests appear in ServiceNow but tickets are not created
- Webhooks are received but no tickets in configured ticket type
Possible causes and solutions:
-
Flow execution errors
- Navigate to Process Automation → Flow Designer → Executions
- Filter by flow name containing "BeyondTrust" or "PMC"
- Check for failed executions and review error messages
-
Missing permissions
- Verify the webhook user has permission to create the configured ticket type
- Check ACLs for the ticket table
-
Invalid configuration
- Review configuration at BeyondTrust Privilege Management → Configuration
- Ensure ticket type is set correctly
- Verify required fields are populated
Troubleshooting steps:
-
Review Flow execution history for errors
-
Check Application Logs for script errors
-
Verify webhook user permissions on ticket tables
-
Test manual ticket creation with the webhook user account
Approval decisions not working
Symptoms:
- Clicking approve/deny buttons shows errors
- Decisions are made but not sent to EPM
- EPM does not receive decision updates
Possible causes and solutions:
-
EPM API credentials incorrect
- Verify Client ID and Client Secret in configuration
- Test connection using BeyondTrust Privilege Management → Test Connection
- Confirm API account has JIT Full Access permissions
-
EPM service hostname incorrect
- Verify hostname includes
-servicessuffix - Example:
acme-services.beyondtrustcloud.com(notacme.beyondtrustcloud.com)
- Verify hostname includes
-
Network connectivity to EPM
- Verify ServiceNow can reach EPM services endpoint
- Check firewall rules allow outbound HTTPS traffic to EPM
-
Ticket state not in active states list
- Verify ticket is in one of the configured active states
- Update active states configuration if needed
Troubleshooting steps:
-
Test connection to EPM from ServiceNow
-
Check Application Logs for API call errors
-
Review EPM audit logs to see if decision API calls are received
-
Verify ticket state matches configuration
Decision validation errors
Symptoms:
- Form validation prevents submitting decision
- Error messages on decision form fields
Common validation errors:
-
"Please enter a reason"
- Solution: Enter text in the Reason field
-
"Enter a number between 5 and 1440" (Minutes)
- Solution: Ensure duration value is within range for minutes
-
"Enter a number between 1 and 24" (Hours)
- Solution: Ensure duration value is within range for hours
-
"You cannot modify the decision because this request is inactive"
- Solution: Ticket is not in an active state. Move ticket to an active state or update configuration to include current state
-
"The server has accepted the decision. It is now final and cannot be changed"
- Solution: Decision has already been finalized by EPM. No further action can be taken.
Logging and diagnostics
ServiceNow logs
Application logs:
-
Navigate to System Logs → Application Logs
-
Filter by:
- Source:
x_bets_pmc_jit - Level: All (or Error for errors only)
- Source:
-
Review log entries for errors or warnings
Flow execution logs:
-
Navigate to Process Automation → Flow Designer → Executions
-
Search for flows related to BeyondTrust
-
Review execution details for errors
REST API logs:
-
Navigate to System Web Services → Outbound → REST Message
-
Filter by messages related to PMC/EPM
-
Review request/response details
EPM logs
Webhook delivery logs:
-
Navigate to Configuration → Webhook Settings in EPM
-
Click on a webhook to view delivery history
-
Review status codes and error messages
Audit logs:
-
Navigate to Reporting → Audit in EPM
-
Filter by JIT-related events
-
Review decision updates from ServiceNow
Debug mode
To enable detailed logging:
-
Navigate to System Properties → All
-
Search for properties starting with
x_bets_pmc_jit -
Set any debug-related properties to
true -
Reproduce the issue and review logs
Testing the integration
End-to-end test: Application Access
-
Configure an EPM policy to require JIT approval for a test application
-
From a managed endpoint, attempt to run the test application
-
Verify:
- User sees "Pending" message from EPM
- Webhook is received in ServiceNow (check Incoming Requests)
- Ticket is created in configured ticket type
- Ticket contains application details from request
- Ticket state is in active states list
-
Open the ticket in ServiceNow
-
Click Approve Application Access
-
Enter reason and duration
-
Submit decision
-
Verify:
- Decision is recorded on ticket
- EPM receives decision (check EPM audit logs)
- User receives access notification
- User can run the application
- Access expires after configured duration
End-to-end test: Admin Access
-
From a managed endpoint, request administrative privilege elevation
-
Verify:
- User sees request submission confirmation from EPM
- Webhook is received in ServiceNow (check Incoming Requests)
- Ticket is created in configured ticket type
- Ticket contains admin access request details
- Ticket state is in active states list
-
Open the ticket in ServiceNow
-
Click Approve Admin Access
-
Enter reason and duration
-
Submit decision
-
Verify:
- Decision is recorded on ticket
- EPM receives decision (check EPM audit logs)
- User receives privilege elevation
- Privileges expire after configured duration
Support
For additional support:
-
Review the troubleshooting section above
-
Check ServiceNow Application Logs and Flow execution history
-
Review EPM webhook delivery logs and audit logs
-
Contact BeyondTrust Support:
- Email: [email protected]
- Hours: US Central Time, Monday-Friday, 2:00 AM - 7:00 PM (excluding US holidays)
- Response Time: Within 24 hours of received support request
When contacting support, provide:
- ServiceNow version
- EPM version
- Application version (from ServiceNow Store)
- Detailed description of the issue
- Relevant log entries from ServiceNow and EPM
- Screenshots if applicable
Security considerations
Authentication and authorization
-
Webhook authentication: Uses Basic Authentication with dedicated service account
- Use strong, unique passwords for webhook user
- Rotate credentials periodically
- Do not share webhook user credentials
-
API authentication: Uses OAuth 2.0 client credentials flow
- Store API credentials securely
- Limit API account permissions to JIT Full Access only
- Rotate API credentials regularly
-
User roles: Follow principle of least privilege
- Only assign
x_bets_pmc_jit.apito webhook service account - Assign
x_bets_pmc_jit.adminonly to integration administrators - Assign
x_bets_pmc_jit.userto help desk staff who need to approve requests
- Only assign
Network security
-
HTTPS required: All communication uses HTTPS/TLS
- Ensure valid SSL certificates on ServiceNow instance
- Verify EPM services endpoint uses valid certificate
-
Firewall rules:
- Allow inbound HTTPS from EPM services to ServiceNow webhook endpoint
- Allow outbound HTTPS from ServiceNow to EPM services
-
IP allowlisting: Consider restricting webhook endpoint access to EPM service IP addresses if supported
Data security
-
Sensitive data: The integration transmits potentially sensitive information:
- User names and IDs
- Computer hostnames
- File paths and application details
- Approval decisions and reasons
-
Data retention: Configure ServiceNow retention policies for:
- Incoming request records
- Application access ticket records
- Admin ticket records
-
Audit trail: The integration maintains audit trails:
- All decisions are logged in ServiceNow tickets
- EPM maintains audit logs of all JIT activities
- Review audit logs regularly for compliance
Compliance
-
Access reviews: Regularly review:
- User role assignments
- Active tickets and decisions
- Webhook user permissions
-
Monitoring: Set up monitoring for:
- Failed webhook deliveries
- Failed API calls to EPM
- Unusual patterns in approvals/denials
Best practices
Configuration
-
Test in non-production: Always test the integration in a development or test environment before deploying to production
-
Document your configuration: Keep records of:
- Webhook URLs and credentials
- API credentials
- Ticket type and state configuration
- Assignment groups and categories
-
Use descriptive names: Name webhooks clearly (e.g., "ServiceNow - App Access - Create") to easily identify their purpose
-
Configure active states carefully: Include all states where approvers should be able to make decisions, but exclude closed or cancelled states
Operational
-
Monitor webhook health: Regularly check EPM webhook delivery logs to ensure webhooks are being delivered successfully
-
Review failed requests: Periodically review incoming request records for any that failed to create tickets
-
Set up notifications: Configure ServiceNow notifications to alert approvers when new JIT requests arrive
-
Define SLAs: Establish service level agreements for JIT request response times and communicate them to users
-
Train approvers: Ensure help desk staff understand:
- How to review JIT requests
- Appropriate approval criteria
- Duration guidelines
- How to use the approval forms
Security
-
Regular credential rotation: Rotate webhook user password and API credentials on a regular schedule
-
Principle of least privilege: Only grant the minimum necessary permissions to users and service accounts
-
Monitor for anomalies: Watch for unusual patterns such as:
- High volumes of denied requests
- Requests for unusual applications or privileges
- After-hours requests
-
Audit regularly: Conduct periodic audits of:
- User role assignments
- Approval patterns
- Configuration changes
Maintenance
-
Keep current: Regularly update:
- ServiceNow application to latest version from Store
- EPM to currently supported version
- Review release notes for new features or changes
-
Test after updates: After updating ServiceNow or the application, test the integration to ensure it continues to function correctly
-
Backup configuration: Export and backup your configuration settings before making changes
-
Document changes: Maintain documentation of all configuration changes and customizations
Advanced configuration
Custom ticket fields
You can customize the ticket forms to display additional fields or hide default fields:
-
Navigate to the form layout for your ticket type
-
Add or remove fields as needed
-
Consider adding calculated fields to display information in custom formats
Workflow customization
You can customize the approval workflows using ServiceNow Flow Designer:
-
Navigate to Process Automation → Flow Designer
-
Find the flows related to BeyondTrust Privilege Management
-
Clone the flows to create custom versions
-
Modify the flows to add custom logic, notifications, or integrations
Be cautious when modifying flows as changes can affect the integration's functionality. Test thoroughly in a development environment.
Custom Notifications
Configure custom notifications for JIT requests:
-
Navigate to System Notification → Email → Notifications
-
Create new notifications triggered by:
- Creation of Application Access Ticket or Admin Ticket records
- Updates to decision fields
- Changes in ticket state
-
Customize notification content and recipients
Integration with other systems
The integration can be extended to work with other systems:
-
SIEM integration: Send JIT request events to your SIEM for security monitoring
-
CMDB integration: Link tickets to configuration items for better asset tracking
-
Identity management: Integrate with identity systems to validate user information
-
Reporting and analytics: Create custom reports and dashboards for JIT activity
Reference
Webhook event types
| Event Type | Description | When Sent |
|---|---|---|
URM_Native_Ticket_Created | Application access request created | User attempts to run an application requiring JIT approval |
URM_NATIVE_DECISION_UPDATE | Application access decision updated | EPM finalizes an application access decision |
JIT_ADMIN_TICKET_CREATED | Admin access request created | User requests administrative privilege elevation |
JIT_ADMIN_TICKET_UPDATED | Admin access decision updated | EPM finalizes an admin access decision |
Ticket type comparison
| Feature | Incident | Change Request | SC Task | SC Req Item |
|---|---|---|---|---|
| Approval workflow | Basic | Advanced | Basic | Advanced |
| Change management | No | Yes | No | Linked to parent |
| Service Catalog | No | No | Yes | Yes |
| Complexity | Low | High | Medium | Medium |
| Best for | Simple approvals | Formal change process | Catalog-based | Catalog-based |
Duration settings
| Unit | Minimum | Maximum | Use Case |
|---|---|---|---|
| Once | N/A | N/A | Single-use access for one-time tasks |
| Minutes | 5 | 1440 (24 hours) | Short-term access for quick tasks |
| Hours | 1 | 24 | Extended access for longer tasks |
API permissions required
| Permission | Purpose | Required For |
|---|---|---|
| JIT - Full Access | Read and update JIT requests | ServiceNow to send decisions to EPM |
Useful ServiceNow tables
| Table | Technical Name | Purpose |
|---|---|---|
| Configuration | x_bets_pmc_jit_configuration | Application settings |
| Incoming Request | x_bets_pmc_jit_incoming_request | Webhook payload capture |
| Application Access Ticket | x_bets_pmc_jit_application_access_ticket | Application access request data |
| Admin Ticket | x_bets_pmc_jit_admin_ticket | Admin access request data |
Additional resources
- ServiceNow Store: Search for "BeyondTrust Privilege Management" for the latest version
- BeyondTrust Documentation: Visit the BeyondTrust documentation portal for EPM configuration guides
- ServiceNow Community: ServiceNow community forums for integration best practices
- BeyondTrust Support Portal: Access knowledge base articles and support resources
Updated 2 days ago