A banking CRM brief should define the customer relationship, the purpose of each data item and the access needed for each task. Keep communication preferences separate from permission to use a channel. Evaluate a proposed system through fictional relationship and access scenarios, with the institution’s approved policies supplying the rules for real customer information.
The central question is not how much information a screen can display. It is whether the right colleague can understand the relationship and complete an authorised task without unnecessary exposure or ambiguous contact instructions. A consolidated customer view needs clear boundaries around both the record and the viewer.
This guide provides an original relationship-and-contact decision sheet. Microsoft’s Financial Services repository and reference architecture supply product examples of profile structures and role-based access; the worksheet turns them into questions a responsible evaluation team can answer with synthetic data.
Microsoft’s documented Unified customer profile reference requires a Power Platform environment created upfront in the United States. The reference environment must have Dataverse and D365 Apps enabled. The deploying user must have an assigned Financial Services add-on licence. These are setup constraints of this specific reference implementation, not requirements for every banking CRM. For a Zambian institution, retain a separate institution-led review of deployment region, data handling, licensing and suitability before contemplating provisioning.
What should the relationship record represent?
Microsoft’s Financial Services repository contains Unified customer profile and Banking data model solutions. Its Unified customer profile is tailored to retail banking and wealth management. The Financial Services repository describes a collection of related solutions. Establish which solution and scenario the proposed demonstration actually uses. Do not interpret a broad suite description as proof that a specific workflow has been configured.
Microsoft describes its Banking data model as a foundation for operational capabilities. Separate the underlying data model from the screens built on it. In an evaluation, ask which entity represents the person, which represents a related organisation or group and which link records the relationship. This gives the team a basis for discussing corrections and access without relying on a polished summary screen.
The reference architecture includes relationships between contacts and customer groupings. The reference architecture makes relationship context part of the profile scenario. For your brief, define the meaning of each relationship and who may create or change it. A displayed connection should not be taken as authority for another person to receive private information or act on the customer’s behalf.
Its financial-holdings view provides details of a customer’s holdings. Decide which tasks need that detail and which need only a limited relationship summary. Give every proposed field a purpose and a responsible owner. Remove fields from the first demonstration when the team cannot explain why the viewer needs them.
How should contact preferences and permission differ?
The reference architecture describes customer-summary information including preferred communication channel. A preferred channel answers where a person would like to be contacted; it does not, by itself, explain which purpose or message is permitted. Keep those questions distinct in the brief and ask the institution’s policy owner to supply the applicable decision rules.
For a proposed contact decision record, include the channel, purpose, source of instruction, recorded time and responsible owner. Record how a changed instruction reaches the systems used for contact. These are worksheet requirements to evaluate, not claims that the cited profile automatically implements the entire consent process.
Use realistic conflict cases with fictional data. One source might show a preferred email channel while another contains a later request about a particular purpose. Define who resolves the conflict and what the colleague should do while it remains unresolved. Avoid making the default action depend on whichever field is most convenient to display.
The repository’s Onboarding essentials combines configurable components with platform components. Configurable components can be part of a proposed solution, but they still need an agreed process. Ask the demonstrator to map the specific purpose and instruction fields to the implemented records. Leave an unsupported requirement open rather than renaming a generic preference field to imply a control it does not provide.
| Evaluation task | Proposed information needed | Access question | Exception to demonstrate |
|---|---|---|---|
| Understand the relationship | Identity and relevant links | Which role needs this context? | Similar names with different customers |
| Prepare an authorised contact | Channel, purpose and current instruction | Who can view or change the instruction? | Conflicting contact records |
| Review a relationship change | Source, approver and affected links | Who can approve the change? | Unverified group association |
| Inspect financial detail | Only detail needed for the task | Which role is authorised for this view? | Viewer should receive a limited summary |
| Resolve an access problem | User role and required task | Who reviews and corrects access? | An intended restriction blocks a legitimate task |
How should controlled access be demonstrated?
The reference implementation lists specific user-role assignments for access. The architecture recommends appropriate role-based access for the dedicated environment’s security group. These documented assignments and recommendations are a starting point for a role review. Record the actual role combination, environment and demonstrated task. A named role alone is weak evidence without testing what the user can see and change.
Create synthetic viewer accounts representing the approved evaluation roles. Define an allowed action and a denied action for each. Inspect the summary, relationship links and any relevant detailed view. Retain the evidence separately for each role so a successful administrator demonstration is not mistaken for ordinary-user access testing.
Include correction workflows. A colleague who can see a wrong value needs a route to report it even when they cannot edit it. Give the correction request an owner and status. Otherwise, restrictive access may protect the field while leaving the operational error unresolved.
Original relationship-and-contact decision sheet
Use a hypothetical customer, a related household member and an unrelated person with a similar name. Add fictional contact instructions with different purposes. Do not use live account numbers or customer documents in this first exercise.
Identity card: Give each fictional person a distinct identifier and explain the proposed links. Ask the reviewer to distinguish a relationship from authority to act. Record the source and owner of each link, then introduce an incorrect association and show the proposed correction route.
Contact card: State the intended purpose of a message, the preferred channel and the fictional instruction relevant to that purpose. Add a conflicting instruction and apply the institution’s supplied rule. If the rule is unavailable, record a policy decision to obtain rather than inventing a legal answer or product default.
Role card: List the task assigned to each test viewer and the data needed. Compare the proposed limited summary with a more detailed authorised view. Record denied actions as deliberately as allowed actions; both are necessary to understand the boundary.
Change card: Propose a changed contact instruction and relationship correction. Identify which record owns the change, who approves it and how downstream users learn about it. Inspect the resulting views with the same test roles, including any remaining discrepancy that needs attention.
Environment card: Record the solution version and demonstration data. For this Microsoft reference, explicitly record the upfront US-created Power Platform environment, enabled Dataverse and D365 Apps, and the deploying user’s assigned Financial Services add-on licence. Have the institution’s authorised reviewers resolve the proposed region, data-handling and licensing decisions before provisioning; keep unresolved Zambia-specific suitability questions open. These conditions belong to this reference, not to all banking CRMs. The reference implementation warns that sample data has no one-click removal option. Decide what synthetic fixture data to use before provisioning the evaluation environment. Keep the trial isolated and retain a clear disposal and recovery plan for its data.
What should the evaluation team take forward?
Produce a requirements record that separates documented product structures, demonstrated configuration and institution-owned policy decisions. Keep missing controls explicit, with owners and evidence needed. The useful outcome is a bounded decision about fit and remaining work, not an unsupported assurance about local regulatory suitability.
For wider systems planning, see business systems and web development. To discuss the technical brief, get started with the fictional relationship-and-contact sheet and the policies your institution has already authorised for the evaluation.
By Spout Team. AI-assisted drafting by Codex using the linked primary documentation.