Components installed with Proactive Engagement

  • Release version: Xanadu
  • Updated August 1, 2024
  • 2 minutes to read
    • Summarize
    Summarized using AI
    This content was generated using new OpenAI-powered functionality. Results are provided on an as is basis and are not guaranteed to be accurate or complete.

    Summary of Components installed with Proactive Engagement

    Activating the Proactive Engagement application (com.snc.selfremediationframework) in ServiceNow installs several key components, including user roles and tables, which enable organizations to engage end-users proactively for self-resolution of issues. These components support configuration, deployment, and management of issue registries, resolutions, notifications, and tracking of engagement experiences.

    Show full answer Show less

    Roles Installed with Proactive Engagement

    Various roles are installed to delegate responsibilities for managing issue registries and engagement configurations:

    • snpren.solutionprovider: Responsible for creating issue registry templates, resolutions, and resolution prompts.
    • snpren.engagementadmin: Manages deployment of issue registry templates, engagement settings, notification channels, fallbacks, and can create custom resolutions and notifications. Note: Access to the Proactive Engagement workbench also requires the SOW user role.
    • snpren.issueregistrytemplatewrite: Can create, edit, read, and delete Issue Registry Template records, resolutions, and notification content.
    • snpren.issueregistrywrite: Similar permissions for Issue Registry and related records.
    • snpren.solutionprovider (read-only): Can read Experience Issue records.

    Key Tables Installed and Their Purpose

    • Proactive Engagement Provider (snprenprovider): Stores details of the DEX solution provider (currently only ServiceNow).
    • Issue Registry Templates (snprenissueregistrytemplate): Holds templates of end-user issues, including descriptions, unique codes, and resolutions. Templates can originate from third-party providers or be customer-created.
    • Issue Registries (snprenissueregistry): Contains deployed issue templates selected by customers for self-resolution. Deployment by Engagement Admin activates the issue for proactive engagement and stores configuration details such as notification and fallback settings.
    • Resolutions (snprenresolution): Stores configured resolutions triggered when metric thresholds are breached, which can include self-help instructions, remedial actions, URLs, or incident creation.
    • Notification Content (snprennotificationcontent): Maintains notification messages and consent prompts related to resolutions.
    • Experience Issues (snprenexperienceissue): Tracks the lifecycle and details of engagements initiated with end-users, serving as the source of truth for proactive engagements.
    • Experience Issue Alert (snprenexperienceissuem2malert): Logs alerts that triggered experience issues, including user throttling details.

    Practical Implications for ServiceNow Customers

    By enabling Proactive Engagement, customers can systematically define and deploy issue templates to engage end-users for self-resolution, improving user satisfaction and reducing support workload. The installed roles allow for clear delegation of responsibilities in managing engagement configurations. The tables provide a structured data model to maintain issue templates, track deployments, configure resolutions and notifications, and monitor engagement outcomes. Customers can expect a scalable and configurable framework to automate proactive user engagement based on detected issues.

    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

    Note:
    The Application Files table lists the components that are installed with this application. For instructions on how to access this table, see Find components installed with an application.
    Table 1. Roles installed with 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
    • This persona is responsible for deploying the Issue registry templates.
    • Configuring the engagement settings, notification channels and fallback.
    • Create a custom resolution and notification for an existing template.
    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
    • Issue Registry Template records
    • Resolution records
    • Notification Content records
    sn_pren.issue_registry_write None Can create/edit/read/delete the
    • Issue Registry
    • Issue Registry Template records
    • Resolution records
    • Notification Content records
    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.