Discover Data Models for Relationship Management and Customer Service
Learning Objectives
After completing this unit, you’ll be able to:
- Describe the data models that help your team manage and build relationships with individual and B2B clients.
- Explain data models to manage customer services and collections.
Relationship Management and Plans
In the last unit, you examined the data models that support the start of the client journey: onboarding new customers, verifying their information, and gathering the data and consents you need to serve them responsibly. But the real work doesn’t stop when a client is in the door. Banks, insurers, and wealth firms build their reputation on how well they nurture relationships and respond when clients need help.
This unit introduces the data models that make that possible. These data models help your teams capture the substance of a client meeting, perform repeated processes consistently, and stay on top of sensitive service scenarios such as complaints, transaction disputes, and collections.
The Interaction Summaries Data Model
The Interaction Summaries Data Model helps bankers and financial advisors save and share notes on client interactions. This ERD shows the Interaction Summary object and how it connects to other objects.

Interaction Summary, the key object in the data model, stores meeting notes in a way that you can share compliantly. For example, check out this screenshot of an interaction summary capturing an account review and needs assessment meeting.

This interaction summary is related to an account, as you can see in the ERD. You can also use it to keep notes on opportunities and account plan objectives as shown in the preceding image. You can relate interaction summaries to any other record where secure notes are useful. The child Interaction object tracks attendees and details about a meeting such as location and time.
These details give you a compliant, secure, and permanent record of your interactions with clients, so anyone assigned to an account can quickly understand that client’s needs and history with your institution.
The Action Plan Data Model
The Action Plan Data Model in Financial Services Cloud helps users create template sets of tasks and document requirements with the Action Plan Template object. Your users can use those templates to create detailed Action Plan records that automatically assign task owners and deadlines for specific client engagements. This helps your team standardize common processes.
Here’s how these objects connect from setup to execution.

For example, you can create an action plan template for financial plan review meetings with clients and relate tasks to the template. The Action Plan Template Item object connects tasks to the template.

When wealth managers are due for a review meeting with clients, they can create an action plan from the template. All the tasks defined in the template are created in the new action plan for that specific client meeting. Each task is connected to the action plan with the Action Plan Item object.
The Action Plan Data Model is a shared feature used by many Salesforce Industries products. See Action Plans in Salesforce Help for details.
The Business Relationship Plan Data Model
The Business Relationship Plan Data Model extends the Salesforce Account Plan object to track information about a B2B client’s needs using interaction summaries, action plans, and other objects.

For example, you can create an account plan for a B2B client’s plan to finance the expansion of their manufacturing operations. The account plan becomes a single hub to track your team’s work and progress with that client, including financial deals, opportunities for new sales, measures toward the client’s goals, and more.
Customer Service and Case Management
In Salesforce, you track customer service with the standard Case object. But financial services institutions like yours have specific needs beyond how cases work by default. Financial Services Cloud includes data models to extend a case’s capabilities, whether you need to track client complaints, disputed transactions, or collections efforts.
The Complaint Management Data Model
The Complaint Management Data Model helps service reps capture, submit, and track client complaints. It does this with two helpful objects: Public Complaint and Case Participant.
Public Complaint tracks customer disputes related to financial transactions. It simplifies adding fields to the standard Case object by tracking complaint information in a dedicated object. This screenshot shows a public complaint that tracks a problem with online banking.

The Case Participant object can relate and define the role an individual plays in a public complaint such as this. For example, case participant records can track if an individual is the direct complainant or a client representative. It also captures communication preferences and authorization details for each participant.
The Transaction Dispute Management Data Model
The Transaction Dispute Management Data Model helps users capture, submit, track, and resolve customer disputes related to financial transactions.
The Dispute object captures the details of a dispute, and the related Dispute Item object tracks the details of a single disputed financial transaction. Disputes relate to the Case object, too, to follow case management processes.
This data model and its objects integrate with Service Process Studio to provide quick configuration of the service process, providing users with a guided, step-by-step experience to resolve disputes quickly.
The Collections Data Model
The Collections data model uses Case alongside other objects to help you streamline collection processes, reduce delinquencies, and maintain customer relationships. Key to this data model is the Collection Plan object.

Collection Plan stores overarching details about a client’s outstanding balances, and can be linked to financial account, billing accounts, cases, contacts, and accounts. Using the Financial Account lookup field it’s easy to know to which Financial Account a Collection Plan is associated with.
Collection Plan’s child object, Collection Plan Item, tracks details about specific invoices or financial account statements that are delinquent. Use these objects and others to prioritize collections and capture promise-to-pay agreements to get clients to pay the money they owe.
For example, if a customer is behind on their credit card payment, create a collection plan for the outstanding amount. Use the financial account lookup field to relate the collection plan to the credit card financial account. Similarly, if a client has three outstanding invoices, create one collection plan with three collection plan items—one for each due invoice.
If a collection plan meets your institution’s criteria for being high priority, you can prioritize it in a queue
What’s Next?
In this unit, you learned about more data models in Financial Services Cloud that support relationship management and customer service. Pretty cool, isn’t it?
Do you know what’s really cool? Integrating data across your organization into the data models you’ve learned about so far.
In the next unit, you explore ways to unlock your data from siloed, disparate systems and make use of all the data-model-goodness you’ve learned about in this module.
