Session Policies: Set Session Permission and Prompting Rules
With session policies, you can customize support session security permissions to fit specific support scenarios. Session policies can be applied to representatives, public sites, and Jump Clients. For full details of how session policies work and how to implement them, see How to Use Support Session Policies.
The Session Policies section lists available policies. Click the arrow by a policy name to quickly see where that policy is being used; its availability for users, rep invites, and Jump Clients; the support tools configured; and the prompting configured. To create a session policy, click Create New Policy, or Copy an existing policy.
Create a unique name to help identify this object. This name helps when assigning a session policy to representatives, public portals, and Jump items. Set a code name for integration purposes. If you do not set a code name, one will be created automatically. Also give this policy a description to further detail the permissions available in this policy. The description is seen when applying a policy to user accounts, group policies, embassies, embassy users, and rep invites.
In the Availability section, choose if this policy should be available to assign to users (user accounts, embassies, and group policies). Also select if it should be available for representatives to use when inviting an external representative to join a session and if it should be available to assign to Jump Clients. If this session policy is already in use, you will see the number of users, public portals, and Jump Clients using this policy.
For all of the permissions that follow, you can choose to enable or disable the permission, or you can choose to set it to Not Defined. Session policies are applied to a session in a hierarchical manner, with Jump Clients taking the highest priority, then support portals, then representatives, and then the global default. If multiple policies apply to a session, then the policy with the highest priority will take precedence over the others. If, for example, the policy applied to a Jump Client defines a permission, then no other policies may change that permission for the session. To make a permission available for a lower policy to define, leave that permission set to Not Defined. For details and examples, see How to Use Support Session Policies.
Set which support tools should be enabled or disabled with this policy, as well as which tools should prompt the customer for permission. Permissions and support tools are described in more detail in Settings and Field Details: User Permissions.
Click Save Policy to make this policy available.
Additionally, you can export a session policy from one site and import those permissions into a policy on another site. Edit the policy you wish to export and scroll to the bottom of the page. Click Export Policy and save the file.
You may now import those policy settings to any other Bomgar site that supports session policy import. Create a new session policy and scroll to the bottom of the page. Browse to the policy file and then click Import Policy. Once the policy file is uploaded, the page will refresh, allowing you to make modifications. Click Save Policy to make the policy available.
Because layering policies can be complex, you can use the Session Policy Simulator to determine what the outcome will be. Additionally, you could use the simulator to troubleshoot why a permission is not available when you expected it to be.
Start by selecting the representative performing the session. This dropdown includes user accounts, embassy user accounts, and rep invite policies.
Next, select the session start method. This can be one of Public Portal, Bomgar Button, Jump Client, Jumpoint, or Local Jump.
If you selected Public Portal, choose the public portal to use for this simulation of an ad-hoc session.
If you selected Bomgar Button, search for a deployed Bomgar Button by profile, associated public portal, associated queue, computer name, or description. The associated public portal will be automatically selected above.
If you selected Jump Client, search for a pinned Jump Client by name, comments, queue, group, or associated public portal. The associated public portal will be automatically selected above. You can choose whether the customer should appear as present or not.
Because local Jumps and Jumpoints are always associated with the default public portal, there are no further settings to define.
Click Simulate. In the area below, the permissions configurable by session policy are displayed in read-only mode. You can see which permissions are allowed or denied as a result of the stacked policies, as well as which policy set each permission.