Implementing ServiceNow for financial institutions often involves balancing consumer and business relationships within a unified data model. This can be especially challenging when authorized users, branch / agency employees, or support teams need to take actions on behalf of customers.
This guide outlines how a financial institution can extend ServiceNow’s out-of-box (OOB) Financial Services Operations (FSO) data model to support complex customer relationships without building a custom application. The approach uses configuration over customization and keeps the platform upgrade-safe and scalable.
1. Understanding the Challenge
In most financial institutions:
- A financial account (such as a savings or business checking account) can belong to either an individual or a corporate entity.
- Authorized users, including employees, joint account holders, or business delegates, need to make service requests tied to those accounts.
- Service teams and front office stakeholders at the financial institution should be able to create and manage cases on behalf of those customers.
ServiceNow’s standard FSO data model is robust but assumes a distinction between consumers and contacts tied to business accounts. That can make it difficult to handle users who operate in both roles or when account relationships don’t follow a simple one-to-one structure. The scope of this guide covers an employee at Alectri Bank (e.g., a branch user) creating a case on behalf of an end customer who holds both business and individual relationships, along with related financial accounts.
2. Start with Contacts, Not Consumers
If an individual customer at the Financial Institution holds both an individual & personal financial account, every external user should begin as a Contact record rather than a Consumer. That said, a contact doesn’t have to be tied to an account which can be done by making the account field not mandatory or removing it from the contact form.
A Contact record extends from sys_user, which allows login and system interaction. A Consumer record is a higher-level abstraction that references a sys_user.
By starting with Contacts:
- Every individual can be represented in one consistent way, whether they are a business contact, a consumer, or both.
- Login and identity management remain straightforward because the record already extends sys_user.
- The model remains flexible for future scenarios, such as portal access or new service workflows.
3. Extend the Related Party Table
To manage which contacts are authorized to act on behalf of a financial account, create an extended table called Financial Account Related Party that inherits from the existing Sold Product Related Parties [sn_install_base_sold_product_related_party] table. The responsibility definition [sn_customerservice_responsibility_def] is only required if a customer is looking to control access for the Contact raising a request from a self-service portal. Otherwise, in our scenario, since it’s the branch user creating on behalf of the contact, all we need is the Financial Account Related Party record.
This extended table:
- Stores roles and relationship types, such as Authorized Representative, Account Manager, or Co-Signer.
- Supports one-to-many relationships between contacts and financial accounts.
- Keeps the original data model intact for upgrade safety while allowing custom fields and behaviors.
Extending Sold Product Related Parties rather than modifying it ensures future compatibility and isolates custom logic from ServiceNow’s core tables.
4. Configure Reference Qualifiers
Next, configure reference qualifiers on the Contact field in the Financial Account Related Party table to ensure any contact can be linked as a related party to a Financial Account.
An example reference qualifier to be used here can be seen below:
javascript: return “sys_class_nameINcustomer_contact”//new Consumer().getConsumerUserReferenceQualifier()
This ensures that when a branch employee creates a case on behalf of a customer, the Account and Contact fields dynamically filter results:
- The Contact field should list any user who has a related record in the Financial Account Related Party table.
- The Financial Account field should display only the financial accounts associated with the selected contact.
This configuration allows branch employees or support staff to easily identify a customer, view their authorized accounts, and initiate a case all from a single form.
5. Simplify the Case Creation Process
While not required, in this scenario we are using the out-of-box Financial Service Case record producer as the foundation for intake. Simplify it to include only the fields required for identifying the customer and their relationship to the financial account.
Recommended configuration:
- Keep a single Contact field to identify the customer.
- Include a Financial Account field for the associated product or service.
- Add a short description or request details field for the service issue.
A small Script Include can handle validation logic by retrieving contact and financial account data from the Financial Account Related Party table. This ensures that only authorized users can initiate cases on specific accounts. For example:
[var CSMUser = Class.create(); CSMUser.prototype = {
initialize: function() {
},
getConsumer: function(userID) {
this.consumerDAO = new ConsumerDAO(userID);
},
getContact: function(userID) {
this.contactDAO = new ContactDAO(userID);
},
getTypeRefQual: function(userID) {
if (gs.nil(userID)) {
return '';
}
return 'sys_idIN' + this.getUserSoldProduct(userID).join(',');
},
getUserSoldProduct: function(userID) {
var userSoldProduct = [];
var rpgr = new GlideRecord('sn_bom_financial_account_related_party');
return userSoldProduct;
},
type: 'CSMUser'
}; ]
6. Manage Access and Security
Because Contact records extend from sys_user, access management can be controlled using standard ServiceNow mechanisms:
- Disable login for non-portal users as needed.
- Use Access Control Lists (ACLs) to control visibility of contact and account data.
- Apply field-level encryption for sensitive information without impacting internal records.
This configuration also prepares the platform for future integration with Customer Access Management to handle more granular access scenarios declaratively.
7. Benefits and Future Readiness
This approach offers multiple operational and technical advantages:
- Flexibility for branch and support teams to act on behalf of customers.
- Compatibility with platform upgrades by extending rather than modifying tables.
- Scalability to support both business and consumer accounts under a single data structure.
- A unified 360-degree view of customers through consistent use of contact and account relationships.
- Secure and role-based access management for all user types.
8. Key Takeaways
When configuring ServiceNow for financial services:
- Use Contact records as the foundation for all external users.
- Extend core tables like Sold Product Related Parties instead of modifying them directly.
- Configure reference qualifiers to control how contacts and accounts are linked dynamically.
- Keep case creation forms simple and intuitive with minimal required fields.
- Plan access control and encryption strategies early for long-term scalability.
Conclusion
By leveraging the out-of-box FSO data model with minimal configuration, financial institutions can build a customer-centric data structure that accommodates both consumer and business relationships. This approach enables authorized actions on behalf of customers, supports future login capabilities, and maintains the integrity and upgradeability of the ServiceNow platform.
