Aggiservice Qualtrics Survey Implementation Logic
- Samuel Irungu
Definition
Aggieservice is an ecosystem with various dependencies used at various stages during the user case lifecycle experience. Qualtrics tool is one of the pluginsplugin hooked within the process. This tool was acquired by the university system to help drive various surveys analysis through collecting review responses data stemming from a customer satisfaction stand point.
Qualtrics as a stand alone Software as a Service (SaaS) has Salesforce enabled plugin extension(s) that is used to receive and send data from and into Aggieservice through defined APIs. Any data received from set endpoints is processed further based on set workflow rules within Qualtrics.
By and large, this marks the end of an Aggieservice Case lifecycle.
Description
The use of Aggieservice(Salesforce) in collaboration with Qualtrics helpshelp drive client (customer) satisfaction response and review agenda.
Shared Service Organization (SSO) is able to track how well or bad Aggieservice is serving the university for all services it delivers.
ItIts is the central place we give case submitters an opportunity to rate how well / bad Aggieservice is serving them. Aggregating the survey responses helps Service Channels understand how effective AggieService has been at meeting their clients needs.
This has been used to help SSO and affiliated teams such as Employe Labor Relations (ELR) monitor the progress of the well being and effectiveness of Aggierservice.
Qualtrics in this use case model, sends survey requests while waiting for responses of the same, ask using data sent by Aggieservice using an API endpoint.
Technical implementation Logic
Functionality implemented through a Record Triggered Flow when certain conditions documented below are met.
The flow is multi-step layered as different types of cases get different type of Survey requests. At the time of this write up, ELR vs Non ELR Case types send different types of survey requests.
Defined Endpoint urls are configured within Workflow Actions in Aggieservice setup under Outbound Messages where these actions are set up.
Upon successful send, The Case in which this operation happens is flagged as having a survey request sent so that future operations that impacts the case do not trigger another send. The update operation (Pink icon in the Flow below) sets Sent_Survey_Email_Checker = true
Notification Recipients
Case Submitter
Point of Contact
Affected Employee(For certain cases) - To be implemented.
Important to note:, The reason why Affected Employees have not been getting Qualtrics is because the nature of the case mattersmatter. For instance, ELR Case record types Affected Employee are not even aware of cases open for or against them and these case types are with restrictions on who even knows about them.
How Its Setup
Survey requests are sent through an established API endpoint provided by Qualtrics but configured under Salesforce Setup as Workflow Actions under Outbound Messages as per the screenshot below.
When
Survey requests are sent / triggered through implemented Salesforce Flow Logic “Closed Case Qualtrics Survey Satisfaction Request” (screenshot) when the following set conditions in a case are met. These conditions may be adjusted as more business requirements come up. At the time of making this technical documentation the following set entry conditions must hold for the this flow to trigger :
Case Status = Closed
Case Origin did not originate from a Phone call
There is a Contact Email / Submitter Email to send the survey to in the cas
There is no previous Close Case survey email sent previously…Just in case the case status is switched back and forth.
Case is not a Test Case (unless there is need to test the same). For Accuracy reporting within SSO
CAVEAT : As noted above current implementation is subject to change over the cause of time as new requirements and business models come up.
Custom APEX implementation
This is a critical step in the process that is called in the Case TriggerHandler in the BeforeUpdate operation which technically happens after a case is created.
This step generates the signing key used in the API call endpoint to provide a unique survey for each call which is a combination of the Case Number and the Submitter / Point of contact.
This logic is implemented in the AddSurveySigningKey() method in the Case_TriggerHandler class called in the BeforeUpdate SOQL Operation. Basically when an existing case is updated and case status is set to Closed, then we suspect / this is a signal that a case is being closed for the first start time or was closed before in which the logic also checks if this operation had happened before.
This operation also checks if a specific individual in the case can receive a survey email based on :
Is the submitter / point of contact email provided?
Has this specific individual submitter / point of contact opted out of receiving any survey notifications in the preference configuration table?
Have they received a survey email specific to this case or not?
Other reasons could come up over the cause of time but this is currently what the logic is evaluating against.
Qualtrics Extension and Plugin Setup implementation
Projects
Currently active Projects in use are :
201910 SSC Service Satisfaction Survey
202002 ELR Service Satisfaction Survey
The project contain the questionnaire for the survey request that goes out to the Submitter / Point of contact.
Workflows
The following 2 workflows are mapped and configured for use by SSO and ELR Teams.
201910 SSC Service Satisfaction Survey
202002 ELR Service Satisfaction Survey
SSC Workflow: Has endpoint for Submitter and POC survey requests
ELR Workflow : Sets up the endpoint for the Case Submitter.
Survey Email Templates
Email survey email templates are hooked to the workflow that draw case data with send these notifications when the API endpoint is triggered mapped to the correct workflow endpoint.
Opting Out Of Survey Requests Response Option
The survey request has a link at the footer where submitters, point of contact or affected employee can unsubscribe from getting these requests. This information is stored in the preference table and is verified before the survey email is sent out.
Strengths
Able to leverage on the already established relationship between Salesforce and Qualtrics through Plugs extension.
Easy to configure.
Established setup is implemented in such away that only one survey review request is sent out and at the right time.
Limitation
Asserting authenticity of the connection between the 2 calls for custom implementation to generate unique signing key. This may require Apex trained resources to help with the change.
Understanding the process could be overwhelming for a non-technical personnel.
Any change request(s) require a well established QA process which takes time to set.
References :
Demo presented to
https://drive.google.com/file/d/1rh5oPmPrrb8rhSBbzsPdg4m4Q9tfZa3A/view
https://docs.google.com/document/d/1pEVS_pcOSNdk1k1EyfdDogCYTNj6lwlqYYYsvi3AVrk/edit?tab=t.0
https://docs.google.com/document/d/1pEVS_pcOSNdk1k1EyfdDogCYTNj6lwlqYYYsvi3AVrk/edit?tab=t.0