Introduction
Who should read this document?
This document is for,
- Architects
- Technical Consultants
- Anyone who wants to adopt a model to accommodate 1:M Contact to Account mapping.
Purpose of this document
This document is aimed to provide specific guidance on how to introduce and establish a solution during a Customer Service Management (CSM) implementation practice, for the customers who are looking to have 1:M contact to account mapping and data maintenance.
The Business Case
A Contact is required to be allowed to raise a Case or a Claim on behalf of multiple accounts, which is managed by 1 contact. This is a requirement required for a customer to provide Self Service via portal and this could be a possible solution for offline cases raised via calling agents as well.
ServiceNow’s Out of the Box (OOB) solution allows 1 Contact to be mapped to only 1 Account and in the scenarios of customer business case, a Contact is required to be mapped to more than 1 Account, the solution need to deviate from the OOB solution. Similarly, if the contact and account data maintenance is handled via any import process on a frequent schedule, how the mapping must be handled.
The Solution Approach
By default, the System Property (Application = Customer Service) sn_customerservice.contact_relationship.restrict_within_account_hierarchy = true. This restricts from having an existing Contact mapped to another Account.
If you want to select any contact from any account for the contact relationship then set the property to false, sn_customerservice.contact_relationship.restrict_within_account_hierarchy = false.
Note: Setting this property to false won’t allow to make use of Account hierarchy structure.
This use case here doesn’t need Account hierarchy model and hence taken this approach.
If you are looking to leverage the Account hierarchy model, this approach doesn’t suit you.
a. OOB Functionality –
“sn_customerservice.contact_relationship.restrict_within_account_hierarchy = true”
In the following example, “Alex Linde” is already a Contact mapped to an Account – “Advanced Routing Components”
In the below image, while trying to map “Alex Linde” forcefully to another Account = “Amaryllis Corp”, the system throws an error stating duplicate entry. OOB behaviour doesn’t allow to have another record inserted to the Contact table.
If you refer to the below screenshot, tried to leverage the Contact Relationship to have another Contact picked the system doesn’t display any other contact other than the one already mapped. In this example of “Amaryllis Corp” Account already have Ruth Wilson as a contact and doesn’t show any other Contacts to relate.
b. Proposed Solution –
After modifying the property “sn_customerservice.contact_relationship.restrict_within_account_hierarchy = false”.
The Contact Relationship allows to displays the list of Contacts from the Contacts table to pick any contact to be mapped/related.
In the below image, Alex Linde has been mapped as an additional Contact to the Account “Amaryllis Corp”.
After mapping Alex Linde as an additional Contact, here is the relationship created for the Account “Amaryllis Corp”.
Raise a Case Scenario – Below image demonstrates Alex Linde has logged into the Service Portal and was able to report a Case against multiple Accounts, for which Alex is listed as a Contact and Contact relationship as well.
c. Data Maintenance Flow -
In the scenario of maintaining Contacts : Accounts in the system via import process, the unique identifier has to be determined. In the below example flow, when the import is executed, it checks for the Contact from customer_contact table and if the Contact is already available and mapped to an Account, then it creates a relationship in “sn_customerservice_contact_relationship”table ensuring the contact is mapped to another Account.
Note: The above flow explains the logic only in the scenario of an Account already available in the Accounts(customer_account) table and trying to have a Contact mapped
4 Comments
