Components installed with Proactive Engagement
Summarize
Summary of Components Installed with Proactive Engagement
The Proactive Engagement application (com.snc.selfremediationframework) installs various components, including user roles and database tables, which facilitate proactive solutions for end-user issues. Understanding these components is essential for configuring and managing the application effectively.
Show less
Key Features
- User Roles: Several roles are installed, each with specific responsibilities:
- snpren.solutionprovider: Manages Issue Registry Templates and related records.
- snpren.engagementadmin: Oversees deployment of templates and configures engagement settings and notifications.
- snpren.issueregistrytemplatewrite: Allows creation, editing, and management of Issue Registry Template records.
- snpren.issueregistrywrite: Manages Issue Registry records and associated resolutions and notifications.
- snpren.solutionprovider: Provides read access to Experience Issue records.
- Database Tables: Key tables include:
- Proactive Engagement Provider (snprenprovider): Stores details of the DEX solution provider.
- Issue Registry Templates (snprenissueregistrytemplate): Contains templates for self-solution engagement with end-users.
- Issue Registries (snprenissueregistry): Holds issues selected for end-user self-solution and their configurations.
- Resolutions (snprenresolution): Stores resolutions for issue thresholds as per defined metric rules.
- Notification Content (snprennotificationcontent): Maintains notification settings for prompts and consent.
- Experience Issues (snprenexperienceissue): Records data on user engagement and resolution states.
- Experience Issue Alert (snprenexperienceissuem2malert): Logs alerts that trigger experience issues, tracking user impact.
Key Outcomes
By utilizing the Proactive Engagement application, ServiceNow customers can efficiently manage user roles, streamline issue resolution processes, and enhance end-user engagement. The structured approach to templates and records ensures that proactive measures can be implemented effectively, benefiting both administrators and end-users alike.
Several types of components are installed with activation of the Proactive Engagement application (com.snc.self_remediation_framework), including user roles.
Roles installed with ServiceNow Proactive Engagement
| Role title [name] | Contains Roles | Description |
|---|---|---|
| sn_pren.solution_provider |
sn_pren.issue_registry_template_write |
This persona is responsible for creating the Issue registry template, Resolution, and Resolution prompt records. |
| sn_pren.engagement_admin |
sn_pren.issue_registry_write sn_pren.experience_issue_read sn_pren.issue_registry_template_write |
Note:
SOW user role is required to access the Proactive Engagement workbench. |
| sn_pren.issue_registry_template_write | None | Can create/edit/read/delete the
|
| sn_pren.issue_registry_write | None | Can create/edit/read/delete the
|
| sn_pren.solution_provider | None | Can read Experience Issue records |
Tables installed
| Table | Table name | Description |
|---|---|---|
| Proactive engagement provider | sn_pren_provider | Record used to maintain the details of the DEX solution provider such as name and provider code. As of today, we only have Servicenow as the provider. |
| Issue Registry Templates | sn_pren_issue_registry_template | This table stores all the end-user issues for which a customer could potentially engage the end-user to self-solve in case of an issue occurrence. Issue registry template records can either come from a third-party DEX/DEX provider or be created directly by the customer, with a reference to the provider. This table specifies the resolution for the issue and how the end user should be engaged, and it holds descriptive fields for the issue, such as Short Description and Description. Additionally, it contains a Unique Issue Code, which is a combination of the Provider Code and Issue Code, ensuring uniqueness across all template records for a customer. |
| Issue Registries | sn_pren_issue_registry |
This table holds all the issues that the customer has chosen for end-user self-solution. An Issue Registry record is created by deploying the Issue Registry template record. Simply having the Issue Registry template record does not make the issue eligible for self-solving; the Engagement Admin must deploy the template to create the Issue Registry record. The table stores all the configurations deployed by the customer, including details on whether a custom resolution and notification were configured by the customer, engagement settings, notification channel settings, fallback options, and template parity status. |
| Resolutions | sn_pren_resolution | Record used to store the resolutions configured to be executed when a threshold breach occurs, as per the metric rule configuration. This record could include a self-help instruction with defined steps, a URL with a specified link, a remedial action with a reference to the configured remedial action, or of type incident creation. |
| Notification content | sn_pren_notification_content | Record used to maintain the notification settings such as notification prompt message and resolution consent prompt |
| Experience Issues | sn_pren_experience_issue | Experience issue record is created once the engagement is initiated with the end-user. This stores data such as user info, State of the resolution execution, end reason state, fallback result (if triggered), investigative details, etc. This record will be the source of truth for any proactive engagement with end-user. |
| Experience issue alert | sn_pren_experience_issue_m2m_alert | Record used to create a log of the alert that caused experience issue. This is a mapping table between alert and experience issues, with details on count of throttled users and throttling reason. |