Contents
In a company with several locations, one customer may work with multiple branches without every employee needing access to every file. A custom CRM must define who may act, on which record and under what circumstances. The difficult decisions arise when an employee changes branches, a customer becomes shared or two teams edit the same record.
Separate customer identity, local relationship and sales file
A shared customer record may hold identity and necessary business contact details. A local relationship identifies the branch serving that customer. A sales file carries its proposal, notes and responsible staff. When these objects are merged into one concept, changing the customer’s branch can move the entire history or hide active files. Decide those consequences before designing the dashboard, and ask the teams who handle exceptions to review the examples.
A custom CRM or ERP can represent responsibilities according to your operations. Define viewing, editing, approval and export separately. Owning a sales file does not necessarily grant the right to approve a discount on it. Head office may need consolidated indicators without access to every local note. Each permission should correspond to an identified task and an owner who can explain why it is necessary.
Use a permission matrix that includes denials
TableExample rules for review with business owners · shareable block
| Proposed access | Boundary to test | |
|---|---|---|
| Local sales representative | View and edit assigned files at their location | Deny confidential notes from another branch |
| Local manager | Reassign and approve within their scope | Deny changes in another branch |
| Shared account manager | View explicitly shared sales files | Avoid implicit access to the entire history |
| Head office operations | View indicators and records needed for the role | Limit exports and personal detail |
| Technical administrator | Manage approved accounts and configuration | Avoid permanent business rights by default |
This is a design proposal rather than a universal policy. Confirm exceptions with the teams involved. Dataverse documentation describes business units, roles and teams, illustrating that permissions can have several dimensions. A custom application must implement and verify its own rules. Borrowing a product’s terminology does not reproduce that product’s security model or prove that a particular implementation protects data correctly.
When a salesperson changes branches
Consider a fictional scenario: Léa moves from the Laval branch to Quebec City. During a business-approved transition she keeps two active Laval files, while her new files belong to Quebec City. A rule based only on her current branch would remove necessary access too early. Keeping all historical access indefinitely would expose records she no longer needs for her work.
In this example, the company chooses temporary assignments on the two files. The Laval manager remains accountable for their progress. A named person receives the task of removing sharing when the transfer ends. This hypothetical workflow does not describe a Daillac customer. The company must choose a review date and ending conditions that fit its organization. A temporary exception needs someone responsible for closing it.
Test less visible effects too: search results, attachments, notifications, exports and saved links. A record denied in the main interface should not remain available through a new export request or an old download link still served by the application. Revoking access does not delete a copy that was already downloaded. Access controls need to apply on the server to the objects involved. OWASP’s authorization guidance recommends denying access by default and checking permissions on every request. Hiding a button alone does not establish an authorization boundary.
When two locations serve the same customer
In another fictional case, Laval and Quebec City create records for the same company. Both sales files remain legitimate. Merging the customer identity should preserve their provenance, owners and histories. Avoid treating a merge as a simple identifier replacement. A mistake could attach a confidential proposal to a wider access scope than the business intended. Show those consequences to the person approving the merge.
Provide a suggested match, review by an authorized person and a preview of consequences before confirmation. Retain the previous record identifiers in the merge history. Conflicting contact details require an explicit decision: which value survives, and what supports that choice? Someone joining the team later should be able to understand the outcome without finding the employee who made the original decision.
Define visible handling for simultaneous changes. An update may be rejected when another version has already been saved, allowing the user to review that change before trying again. Developers will choose the appropriate mechanism, but the business must decide whether an update can silently overwrite another. A custom web application should explain that behaviour clearly enough for staff to recover without guessing.
Acceptance scenarios for organizational changes
TableFictional scenarios to run before launch · shareable block
| Action | Expected outcome | |
|---|---|---|
| Laval salesperson | Open an assigned file and another branch’s file | First allowed; second denied without sharing |
| Léa changes branch | Update location and open a transition file | Access limited to temporarily assigned files |
| Transition ends | Remove sharing and retry a direct link | Old access denied and history retained |
| Quebec City manager | Reassign a Laval sales file | Denied under the agreed matrix |
| Customer merge | Join two identities with local sales files | Provenance and file permissions preserved |
| Concurrent update | Save competing changes to one record | Conflict handled under the approved rule |
| Consolidated export | Export through a restricted head-office role | Excluded fields absent from the file |
For each scenario, record the accounts used, starting state and observed result. Include secondary routes such as direct URLs, global search and attachments. Repeat affected cases when a role or integration changes. These examples provide an initial acceptance grid; no tests were performed for this article. The actual test package needs organization-specific data, approved rules and a business owner who can accept the result.
Apply the same boundaries to automation
CRM and ERP automation often operates through a service account. Give it the scope it needs and record the target file and origin of the request. A synchronization process should not turn local sharing into general access. Check how it responds when someone loses a permission while a queued task is still waiting. The business must decide whether that task may proceed and how its decision is recorded.
Assign the matrix to a business owner and review organizational changes before enabling them. Maintain an exception register with reasons and review dates. Acceptance comes from concrete situations: employees can complete their work, expected denials hold, and decisions remain understandable when a file passes between locations. Keep the approved matrix with the test evidence so future changes have a documented starting point.
Related implementation guides
Multisite CRM questions
Must a customer belong to only one branch?+
A shared identity can coexist with local relationships and sales files. Commercial ownership and access permissions should be defined separately.
Does head office need every local note?+
That depends on its tasks. Consolidated indicators may be enough for some roles; details and exports require explicit permissions.
What happens when an employee changes location?+
Review access and active files, define any necessary temporary sharing and assign someone to remove it when the transition ends.
How should duplicate customers be handled?+
Use detection followed by a controlled merge with provenance, preserved permissions and review of conflicting contact details.
Define your multisite CRM rules
Bring a branch-transfer scenario and a shared customer example to define the permissions that need verification.
D
