One Customer, Multiple Teams: How to Stop Duplicating Business Data

Sales calls the customer “Northbridge”. Delivery uses “Northbridge Estates Ltd”. Operations has a third version in its contract register, with a different contact and an old address.

Everyone has a customer list. Nobody is sure which one to trust.

Duplicating customer data usually begins with a reasonable decision. Each team needs a different working view, so each creates its own tracker. Over time, those trackers become separate records of the same business relationship. A change in one rarely reaches the others without someone remembering to pass it on.

Connecting the records lets teams keep their own work processes while sharing the customer information they depend on.

Separate the customer from the work

In our fictional example, Alder Services provides operational support to Northbridge Estates. The relationship involves a service contract, an onboarding project, ongoing requests and a future renewal review.

Northbridge Estates is one organisation. The contract, project, requests and renewal work are separate things connected to it.

That distinction gives you a practical starting structure:

A named contact for one contract may differ from the person responsible for a delivery project. Store that context on the relevant relationship instead of repeatedly overwriting one general “customer contact” field.

The same principle applies to suppliers. In our contract renewal tracker, Beacon Maintenance has one organisation record linked to its agreement. The structure supports both sides of the business without treating every activity as customer data.

Choose who maintains the shared information

Before connecting tables, agree who owns the organisation record and what identifies it.

Give Northbridge Estates a stable reference, such as ORG-001. Use that reference to distinguish it from similarly named organisations. Decide who can create a new organisation and who checks whether one already exists.

Agree where changes belong. The relationship owner might maintain the organisation name, while delivery managers maintain their project records and contract owners maintain agreement details.

Historical information needs its own treatment. If an approved document records the address or terms at the time of signing, preserve that version. Linking current operational data should not erase evidence of what was previously agreed.

Connect teams within one project first

For a small team, one Gridfox project with linked tables may be enough. Organisations can connect to Contracts, Delivery Projects and Service Requests through one-to-many relationships.

Each team can then use views suited to its work. Delivery might use a board for project stages. Operations might use a grid sorted by notice deadline. The relationship owner can open the organisation and inspect the linked records.

This avoids a common mistake: putting every detail into one enormous customer table. A row with several contracts, multiple deadlines and a growing set of service issues soon becomes difficult to maintain. Separate records give each piece of work an owner and a lifecycle.

Use cross-project relationships where the work needs separate projects

Some teams already have distinct Gridfox projects for customer records, delivery and operations. Gridfox supports relationships between tables in different projects, so work can reference a shared organisation without maintaining another customer list.

For Alder Services, that could mean keeping Organisations in a shared business-records project, with delivery projects and operational contracts linking back to it. Gridfox’s platform review describes cross-project relationships and their use for shared client records.

Plan the connection around a specific handover. For example: when delivery takes on a new Northbridge project, it should select the existing organisation record and create its own delivery record. It should not copy the organisation into a new customer table.

Check the relationship and visibility with the actual user groups before expanding it. Different projects may have different audiences, and a link between records is only useful when the right people can use it appropriately.

Keep access separate from presentation

A cleaner view helps someone focus. It does not decide what they are authorised to see.

Use group permissions to control table, field and record access. Test with representative users rather than assuming an administrator’s view reflects everyone else’s experience.

A delivery coordinator may need the organisation name and project contact without needing access to every commercial field. A contract owner may need agreement details without editing the shared organisation record. Make those decisions deliberately as you connect the work.

Prove the model with one customer

Choose an organisation that appears in several trackers. List its duplicates, agree which record will become the maintained version and link a small set of operational records to it.

Then test an ordinary handover. Can the delivery manager find the right organisation? Can operations locate the relevant contract? Can a colleague distinguish an open service request from a renewal decision?

You will learn more from those questions than from connecting every table at once.

Once the structure works, the next task is moving existing data into it without carrying every duplicate and workaround forward. That is the focus of the next article in this series, From Spreadsheet to Business System: A Practical Migration Guide.

Talk to Gridfox about a customer handover that currently involves copying data. We can help map the shared record and the work that should connect to it.