What actually changes when the org belongs to a bank

A bank, an insurer, a hospital and a utility are not obviously the same customer. They sell different things and answer to different oversight. Put a Salesforce programme inside any of them and the delivery starts behaving the same way, because they share one property: somebody outside the organisation has the standing to ask what happened, and the organisation is obliged to answer.

That property changes the work. The platform is identical and the features are the same. What differs is that every design decision now has a second audience: somebody who was not in the workshop, will read the result years later, and will judge it on evidence rather than outcome.

None of it is insurmountable. All of it is cheaper to plan for than to discover.

#The entity you are modelling is not a customer

Commercially the account model is close to self-evident: a company, some contacts, perhaps a hierarchy. Regulated organisations rarely deal with a single party. A bank services a household, a trust with a corporate trustee, and a business owner who is also a guarantor on somebody else's loan. An insurer holds a policyholder, an insured life, a beneficiary and a broker. A hospital holds a patient, a guardian, a nominated carer and a referring clinician. A utility holds an account holder, an occupant who is not, and a person at the premises with a medical dependence on supply.

The same human appears in several roles across several groupings, and the roles carry different rights. Some are commercial; some are obligations the organisation cannot decline once it knows. That is what the group and relationship modelling in the industry clouds exists to hold, and why a generic account and contact design fails here. Not because it cannot store the data, but because it cannot answer the question. Three questions drive the design:

• Which groupings does the business service, report on and owe a duty to?
• For any person, what should a staff member see, and what must they not see, when that person appears inside somebody else's grouping?
• Which relationships are commercially useful, and which create an obligation the moment they are recorded?

Settle those before choosing objects. The third is the one a commercial project never has to ask.

#What the access model has to do that it normally does not

How Salesforce decides who sees a record is the same in every org, and we have set that order out separately in designing the access model on purpose. Regulation does not change the order. It changes what the model is asked to prove, and adds three requirements a commercial org almost never carries.

It has to say no, not only yes. Two teams inside one firm that must not see each other's clients. A claims handler who must not touch a claim they are party to. A clinician outside this patient's care. A retail function that must not see a wholesale position. Access that would merely be untidy commercially is a finding here, and a model assembled entirely out of grants cannot express a prohibition.

Somebody has to have approved it, visibly. Commercially, the justification for a grant lives in a ticket if it lives anywhere. Here the grant, the approver and the review date are themselves records that get requested, which makes them a data model decision rather than an administrative habit.

It has to survive people changing jobs. Recertification, leavers, secondments, contractors, and time-bound access that actually expires. A commercial org finds stale access during a clean-up. A regulated one is expected to detect it on a schedule and to show the schedule ran.

None of that needs unusual features. It needs the review to have been designed rather than promised.

#Evidence is a design input

Who changed this, and when, is a commercial nice-to-have added when somebody asks. Here it is a requirement, asked about formally, and it has to be true retrospectively. That last part catches teams out, because evidence cannot be produced later for a period in which nothing was capturing it.

• Field history records only from the moment it is enabled and never backfills. Which fields are tracked is a design decision, not a later tidy-up.
• Retention of that history is a separate decision, because standard retention is frequently shorter than the period the organisation is obliged to keep. Establish the obligation, then choose between extended retention and an archive, before go-live.
• Who viewed a record, as distinct from who changed it, is a different capability with its own cost, and for customer, patient or member data it is very often the question actually asked.
• Consent and communication preference need a defensible record of what was agreed, when and through which channel. A checkbox whose history is unknown is not a record of consent.

Treat the evidence pack as a build artefact rather than a document assembled under pressure. Test results, approvals, migration reconciliations and access decisions are cheap to capture as they happen and expensive to reconstruct.

#Who is allowed to see production data

This is the constraint commercial teams underestimate most, because it changes how the team works rather than what it builds. Production data is usually restricted to a small named group, and delivery people are frequently not in it. External consultants are almost never in it.

• A defect that reproduces only on real data cannot be investigated by the person who wrote the code. It has to be described by somebody who can see it, to somebody who cannot, which is a slow and lossy channel.
• Sandboxes cannot simply be seeded from production. Data has to be masked or synthesised, and masked data has different shapes, volumes and edge cases from the thing it stands in for.
• Support runs on descriptions and screenshots rather than records, which makes intermittent faults genuinely hard rather than merely annoying.
• Break-glass access, where somebody is granted production visibility to resolve an incident, has to exist before the incident, with an approval path, a time limit and a record. Improvised elevation during an outage is the finding that outlives the outage.

Plan for this in the delivery model rather than the risk register. Make representative test data a build task with a named owner, write the defect intake template so it captures what a person without record access needs, and agree the break-glass path during design rather than in the middle of an incident.

#Residency, and what it rules out

Where data is stored and processed is a contractual question with a specific answer, and it behaves as a constraint rather than a preference. It decides which environments, regions and services are available, and what may leave the tenancy at all.

It deserves its own conversation because it rules things out silently. A capability can be well designed, wanted by the business and simply unavailable, because it processes data somewhere the organisation has committed not to. That is now the routine early question for anything with an AI component: which model, running where, on whose data, retained for how long, and used for training or not.

Get a straight answer before a design depends on it. It is usually narrower than the platform's global capability and broader than the first person you ask believes.

#The pace of delivery, and the change advisory board

Iterative delivery survives contact with a change advisory board, but not in the form most teams practise it.

The usual agile answer to uncertainty is to ship small and learn in production. Regulated change governance is built on the opposite premise: a change is described, assessed, tested, evidenced and approved before it moves, by people who were not in the sprint. Treating that as obstruction spends credibility you will need later. It reflects an organisation answerable for its changes in a way a commercial one is not.

• The board meets on a fixed schedule, so the release calendar is set outside the team.
• Approval needs documented test evidence, signed, in advance rather than after.
• Freeze windows sit around reporting periods, year end, submission dates and seasonal peaks, and they are not negotiable for a feature.
• Anything touching customer, patient or member data needs a written and tested rollback, not an intention to roll back.
• Whoever builds a change is often not permitted to deploy it, which changes the pipeline and the roster, not only the process document.

Keep the iteration and change the unit: iterate on design, prototypes and configuration in lower environments at ordinary speed, then batch into releases sized to the approval cycle. Teams that insist the sprint boundary and the release boundary are the same thing spend their capacity on paperwork for changes nobody was waiting for.

#Vendor assessment, and the weeks nobody scheduled

Any new tool, managed package, integration endpoint or subprocessor may require a security and vendor assessment, and that queue is not controlled by the project. It routinely takes weeks, longer where the vendor is small or the questionnaire is bespoke, and it applies to things that feel uncontroversial: a document generation tool, a survey service, a masking utility.

Submit in week one, before the design hardens around the assumption, and ask whether the vendor has been through this organisation's assessment before, because one with existing answers moves in a fraction of the time of one drafting them.

The failure mode is rarely rejection. It is a design that assumed a component, a build that started anyway, and an assessment that concludes after the component became load-bearing.

#Retention and deletion pull against the defaults

Platform defaults assume you want to keep things. Regulated obligations pull both ways at once: some records must be kept for a defined period, some must be deleted or de-identified once their purpose ends, and the same person can be subject to both.

• A deletion that is genuinely a deletion, reaching history, archives, sandboxes, integrated systems and anything already exported into a report or a warehouse.
• A retention clock that starts from an event, the end of a relationship, the closure of a claim, the last episode of care, rather than from the record's creation date.
• A defensible position on what leaves the tenancy at all, because a downstream copy carries its own retention and its own obligation.
• Evidence that the deletion happened, which is itself a record you now have to keep.

Design the lifecycle alongside the object. A retention rule bolted on afterwards has to reason about records created before the rule existed, and the field it needs is usually the field nobody captured.

#The constraints, and the design decision each one forces

The useful artefact for an early conversation is not a compliance checklist. It is a statement of what each constraint changes about delivery, because the decision it forces is the thing nobody scheduled.

Read the middle column when you plan and the right-hand column when you design.

#What gets asked for after an incident

Incidents are where the decisions above stop being theoretical, and the questions afterwards are consistent across sectors.

What was accessed, by whom, and when. Whether that access was authorised, and by which grant. What changed, in what order. Who approved the change that preceded it. Which customers, patients or members were affected, precisely rather than approximately. What was communicated to them, when and through which channel. And whether the control that failed was working before it failed, which is a question about monitoring rather than configuration.

Almost every one is answerable only from evidence captured before anybody knew there would be an incident. The organisation that answers in a day does not have better controls than the one that takes three weeks. It has controls that were producing a record all along.

Underneath sits a quieter question: how long did it take you to notice. An org with no view of viewing and extraction has no honest answer, and the absence becomes the finding.

#The rule, and somebody's interpretation of the rule

The last thing worth saying is the least comfortable, and it holds in every regulated sector.

Most of the constraints handed to a delivery team are not the regulation. They are the organisation's interpretation of an obligation, made once by somebody sensible, hardened into an internal standard, and repeated since by people who inherited the standard rather than the reasoning. Interpretations drift conservative, because being too strict is paid for by delivery teams and being too loose is paid for by the executive who signed it off.

That matters because some constraints are genuine and immovable, some have outlived the architecture they were written for, and they arrive in the same tone of voice.

Three questions tell them apart, asked without any edge. Which obligation does this control satisfy? Who owns the interpretation? When was it last reviewed against how the platform works now?

Asked well, it is a welcome conversation, because risk and compliance functions usually know which of their standards predate the current platform and rarely have a reason to revisit one. Asked badly, it reads as a delivery team arguing its way out of a control, and it costs you the relationship you need for the harder conversations later.

Test the constraint, accept the answer, and write down which ones you tested. The next project will be handed the same list.

#What good delivery looks like here

The pattern that works is not slower delivery. It is front-loaded decision making: more design, earlier involvement from risk, compliance and security, and evidence produced continuously.

Teams that treat compliance as a gate at the end deliver twice, once for the business and again for the reviewer. Teams that bring those functions into the design workshops deliver once, and the review confirms rather than discovers. Nothing about that is exotic. Their delivery plan already contains the assessment queue, the freeze calendar and the evidence pack, and they stopped treating those as interruptions some time ago.

More on how we work in this sector: Salesforce for financial services.