One person may buy for several companies, change employers or advise more than one account. A single company-name field on the contact can lose that context. Decide whether you are storing a person, an organization or the relationship between them.
Related service: CRM, ERP and web application development- 01Create the person and organization records.
- 02Describe their business relationship.
- 03Attach role-specific activity.
- 04Close or update the relationship.
- 05Preserve relevant historical context.
SECTION 01
Choose the relationship your process actually needs
A simple business may need one current employer per person. Others need several organizations, branch-specific contacts or consultants acting for different customers. Ask which relationship staff need to search, report on and authorize. Do not introduce a complicated network model merely because it is technically possible.
Microsoft's relationship documentation illustrates one-to-many and many-to-many models. Those are reference options, not a claim that this project requires Dataverse. A custom model may give the relationship its own start date, end date, role and preferred address. Database references should preserve valid links, while application rules determine whether an ended relationship may receive new work.
SECTION 02
Illustrative example: a consultant representing two buyers
Suppose a procurement consultant assists two unrelated customers. Staff use one person record but create a separate relationship for each customer. A product inquiry for the first buyer stays with that account even though the same person later sends a request for the second. This hypothetical example is not client evidence.
An account portal invitation needs an explicit account and role. Matching the consultant's email address should not grant access to both customers. When one assignment ends, revoke that membership while preserving the old inquiry's history. The contact remains useful without treating a historical commercial connection as permanent authority to read documents.
SECTION 03
Demonstrate changes without rewriting history
Begin with the relationships required for one team. Existing CRM account-contact features may already fit, so compare configuration with a custom relationship model. Consider the reporting and permission consequences before choosing a simpler field just to make the entry form shorter.
Test a changed employer, two active relationships, a shared office email and a company merge. Ask how imports will identify the right relationship and how an export represents it. A completed opportunity should keep its original customer context after the person moves elsewhere. Include a readable way for staff to see current and past roles, avoiding an ambiguous list of company names with no dates or purpose.
SECTION 04
Frequently asked questions
Do we need a new contact for every company?
Not necessarily. One person can have several explicit organization relationships, provided activity and access remain attached to the correct business context.
Should old opportunities move when someone changes jobs?
Usually they retain their original customer relationship. Define the rule explicitly instead of deriving history from the person's current employer.
Can email matching grant portal membership?
Email can identify a person, but account membership needs a separate authorized decision. One address should not automatically join every related organization.
PRIMARY REFERENCES
Sources and further reading
These references cover the standards, platforms, or published prices discussed in the guide. Worked examples and checklists are our editorial guidance.
- Table relationships and their behaviorMicrosoft Learn
- Database constraintsPostgreSQL
EDITORIAL METHOD
About this guide
We use AI to assist with drafting and editing. Catapult AI Work is responsible for the published content. Examples illustrate possible approaches; they are not client case studies unless identified as such.
Budget examples are not Catapult package prices. Check linked provider pages for current fees and plan limits before making a purchase.
Read the editorial policy