Relationships

Almost every system of this kind has a Contacts table and a Companies table, and the first thing it asks you to do is decide which one a record belongs in. That seems like an easy question until you meet the ordinary cases, and the ordinary cases are most of them.

A sole trader is a person you invoice, and next year they incorporate. A husband and wife run a business together and the relationship is with both of them. Your client is a partnership, and the partner you deal with is the reason you have the work at all. A candidate is a person today and a hiring manager in three years, at which point they are a client. In every one of those, the answer to whether the record is a person or a company is that it is both, or that it changes.

What organisations actually do when a system insists on the distinction is predictable. They pick one, they work around it, and the workaround becomes the institutional knowledge. Someone types a household into the company name field. Someone creates a company called Smith Family so the address has somewhere to live. Someone keeps a spreadsheet of which contacts are really companies. Every one of those is a small tax on everybody who joins afterwards and has to be told.

What Consonas does instead

A relationship is one kind of thing with a kind attached. A person is a relationship whose kind is person. An organisation is a relationship whose kind is organisation. They live in the same place, they are searched together, they carry the same timeline, the same files and the same consent, and the difference between them is a property instead of a wall.

The people at an organisation are connected to it rather than stored inside it, which is the second half of the same decision and the half that matters when someone leaves. A contact stored inside a company disappears when you change their employer. A person connected to a company keeps everything they were, and the connection carries the dates so you can still answer who was there in 2023.

The word your business uses

The other thing most systems fix in advance is what the relationship is called. Customer, if you are lucky. Account, if the system was designed for enterprise sales. Neither is the word a membership organisation, a letting agent, a recruitment consultancy or a legal practice actually uses, and the word matters more than it looks.

It matters because it is what people type into search. If your team says client and the system says account, everybody performs a small translation every time they use it, and the people who perform it least reliably are the new ones and the busy ones. Relationship types in Consonas are configuration held against your organisation. You name them. You can add one, rename one or retire one without asking anybody, and records carrying a retired type keep it rather than being silently reassigned.

Duplicates are found, not prevented

Every system promises to prevent duplicates and every system has them, because the ways a duplicate is created are not all things software can see. Someone types a name with an initial. A form is filled in with a personal address rather than a work one. Two people import overlapping lists a fortnight apart.

Consonas checks at the three points where checking is cheap and useful, and it is not the same check in all three. Typed in by hand, it matches on email address and on close name matches, and shows you what it found beside the record for you to judge. Imported from a file, it does the same and compares the rows in the file with each other as well. Submitted through a form, it matches on the exact address and nothing else, because nobody is standing there to be asked and two people of one name is an ordinary thing: when it finds one, the visitor is shown nothing, the enquiry is attached to the person it matched, and a line goes on their timeline saying so. Nothing is merged for you in any of the three.

Silent merging is the tempting design and it is the wrong one. Two records that look identical are occasionally two different people, and a product that guesses will eventually guess about someone who matters. Being shown a possible duplicate takes four seconds. Discovering that two customers were combined into one six months ago takes an afternoon and a difficult telephone call.

Merging keeps both histories

When two records genuinely are the same person, merging them produces one record with both timelines interleaved in order, both sets of files, both sets of connections and both sets of consent records, with the more recent consent state taking precedence and the older one still visible as history.

The merge itself is an event in the timeline and in the audit trail, naming who did it and what was combined. That matters because a merge is the one editing action that is genuinely hard to reason about afterwards, and knowing that two things used to be separate is often the explanation for something that looks wrong later.

The discipline that actually pays

The advice we would give any organisation starting with this, and it is not specific to us, is to import less than you think you should. The instinct is to bring in everybody who has ever emailed the business, because it feels like the data is free and might be useful.

What that produces is a system where search returns four plausible records and no one knows which is current, where marketing lists are full of addresses that bounce, and where the number in the corner tells you nothing about the business. A thousand relationships someone would recognise is worth more than nine thousand that include everyone who once asked for a price. You can always import the rest later, and you very rarely want to.

Search is for when you know who you want

Type a name, part of a name, an email address, a telephone number or a word from a note, and search returns matching relationships across every kind and type at once. It searches people and organisations together, which is the practical benefit of holding them together: you do not have to know which one you are looking for before you look.

It respects permission completely. A record you are not allowed to open does not appear, and a sensitive record you do not hold the grant for is genuinely absent rather than shown as a locked row. A search result that says there is something here you cannot see is a permission leak wearing a helpful face: it confirms the existence of the record, and often the name, which is frequently the sensitive part.

Views are for when you know what you want

A view is a filtered, sorted, column configured list you keep. Customers in Kent with no activity for ninety days. Suppliers whose contract renews this quarter. Members whose consent has lapsed. Every one of those is a question you ask repeatedly, and a view turns it from a search you reconstruct each time into a tab you click.

Views can be private or shared with the organisation. The shared ones matter more than they sound, because a shared view is how a team agrees what a category means. When someone says the at risk accounts, a shared view makes that a definition instead of an opinion, and when the definition changes everybody's list changes with it.

Columns, sorting and export

Any list can be given the columns you want, sorted by any of them, and exported as it stands. That last part is deliberate: the export of a view is the view, not a generic dump you then have to filter again in a spreadsheet. If you have built the question in the product, the answer should come out in the shape you built.

Ownership is about allocation

Every relationship has an owner, and a role can be scoped so that somebody sees what they own instead of everything. That suits a sales team with allocated accounts, a practice where each client has a responsible partner, or an agency where each account has a lead.

Ownership is not secrecy. It is a statement about who is responsible, and the usual configuration is that managers see everything while the people doing the work see theirs. It changes when the person changes, and the change is recorded.

Sensitivity is about the specific record

Marking a relationship sensitive is a different action with a different meaning: this particular record should not be visible to people who can otherwise see records like it. A grievance. A client who is also an employee. A customer in a dispute. Somebody whose circumstances are nobody else's business.

Sensitivity requires a grant held separately from the role, so it is not something that arrives as a side effect of a promotion, and removing it does not require rebuilding someone's permissions. It is respected by search, by reports, by the portal and by export, each checked separately rather than relying on one gate.

Why they are not one setting

Because they answer different questions and combining them forces a false choice. An organisation that only has ownership scoping ends up making managers owners of things they do not manage, so that they can see them. An organisation that only has sensitivity ends up marking half the database sensitive, at which point the mark means nothing.

Keeping them apart means the common case stays simple. Most organisations use ownership and never touch sensitivity, and the ones that need sensitivity usually need it for a handful of records rather than for a category.

A purpose and a channel, treated as one pair

Consent is not one permission per person. It is held against a purpose and a channel together, because the newsletter by email is a different fact from service notices by email, and both are different again from either by telephone. The current position for any pair is the most recent entry recorded for that pair, so a withdrawal against one leaves every other pair exactly as it was.

That is more tedious to set up than a single switch, and it is what stops an organisation doing the thing organisations eventually do, which is treating one agreement as permission for everything.

The basis, claimed at the time

Every entry names the lawful basis being relied on, because consent given on a form and a legitimate interest relied on for service mail are not the same claim and are not defended in the same way. When the product is asked whether something may be sent to someone, the permission it returns names the basis it allowed it on, in words, rather than being a bare yes.

A refusal names its reason for the same purpose. Consent was withdrawn is a different answer from nothing was ever recorded, and the two lead to different conversations with different people.

The wording that was on the screen

Alongside who, what and when, an entry holds the exact wording the person was shown at the moment they agreed. That is the field that matters if anybody ever asks, because the question you will be asked is never whether a box was ticked. It is what the box said. A form on your own website records that wording without anybody choosing to, which is the only way it is reliably there a year later.

Where it came from, and who wrote it down

Each entry carries a source, the moment it was recorded, and the member of staff who recorded it where a person instead of a form did. Withdrawal is a new entry rather than an edit of the old one, so what you hold is a list in order instead of a field that only remembers its current value, and the whole list for one person can be read end to end.

Where there is no entry at all for a purpose and a channel, sending is refused rather than quietly permitted. That is the decision on this page most likely to annoy you in the first fortnight, because a list you have just imported arrives with no consent history and therefore cannot be written to until something is recorded. It is correct and it is still irritating, and we would rather say so here than have you discover it on a Tuesday afternoon.

A person whose organisation you may not open

Ownership scoping and sensitivity apply to organisations exactly as they apply to people, so it is entirely possible to be allowed to see someone and not allowed to see the firm they belong to. When that happens the employer is simply absent from the record: no name, no greyed row, nothing that confirms there is something there you cannot reach. Showing the name and refusing the click would disclose the part that was meant to be withheld, which is usually the name.

A record someone has deleted

Deleting a relationship puts it in the recycle bin for thirty days rather than removing it. During those thirty days, opening it directly answers exactly as it would for a record that never existed, which is deliberate: a deleted record should not stay reachable through a link somebody kept in an email. The bin lists what is in it, with who deleted each one and when, and it applies the same visibility rule as everywhere else, so it cannot become a way of seeing what you could not see before it was deleted. After thirty days the removal is permanent, and what remains is the audit trail's statement that it happened.

Someone who asks you to stop rather than to forget

Restriction is a mark on the relationship itself. The record stays, stays readable, and stops being written to. It is what somebody asks for when they dispute what you hold and want it left alone until that is settled, and it is deliberately not modelled as a withdrawal of consent, because a withdrawal would be undone the next time they filled in one of your forms while the dispute was still open.

Erasure, where the record is yours rather than theirs

Erasing somebody removes the things that are about them: the consent history, the timeline, audience membership, campaign recipients, sequence enrolments, meeting attendance, feedback, their portal account, and any company details held against them. The things that are your organisation's own records are kept and detached instead. An invoice, a contract, a quotation, a matter, a project: each stops naming anybody instead of disappearing, because destroying your accounting record in order to satisfy an erasure request would break one obligation in the act of meeting another. Where exactly that line falls is a question the Information Commissioner's Office answers at more length than we can here.

Which side of that line a given record falls on is a judgement instead of something that can be worked out from the shape of the data, so it is written down once, in one place, and a test refuses to let a new kind of record that names a person quietly avoid the question.

An organisation that changes while nobody is looking

Where a customer is a company on the Companies House register, the record can hold that company's public details, fetched once because someone asked and then kept. Nothing about opening the record calls out to anyone, which is why a record with company details on it opens as quickly as one without. The refresh afterwards takes the stalest company, one per nightly wake, on the grounds that an organisation with four hundred company records should not spend four hundred requests in a single moment.

A registration check is recorded differently again, as a moment rather than a field: what was checked, the registered name that came back, and the date someone checked it. A field that quietly claims to be current is worse than a date that admits how old it is.

And when the change is bad news

Changes published against a company you hold are graded rather than merely listed. An insolvency case, or a notice published to strike the company off, is urgent. A charge registered against its assets, accounts filed late, or a director resigning is a concern. A change of name, or a charge satisfied, is worth recording and not worth interrupting anybody for. All of them appear on the timeline in the same place as everything else that has happened with that customer.

Only the urgent ones raise a task, at the top of the priority scale the rest of the product uses, owned by whoever owns the relationship. The restraint is the whole point. A task for every change of registered name is how the insolvency task ends up being ignored as well, and the same change arriving twice does not produce two entries, because a history that repeats itself stops being read.

A custom record type is Enterprise, and it belongs to one party. The property, the site, the asset described above is on the Enterprise plan and on nothing below it, and each record of that kind attaches to a single relationship. Something that genuinely belongs to two parties at once, a tenancy with a landlord and a tenant, has to pick one of them and reach the other through a connection. Their fields are also not something a list can be filtered on, which is worth knowing before you design a year of work around them.

A merge cannot be undone. Merging moves the history onto the surviving record and closes the other one permanently. There is no unmerge, the closed record does not come back out of the recycle bin, and the exemption is deliberate rather than an oversight. That is why there is a preview showing exactly what is about to move before any of it moves. Read it, because it is the only moment at which this decision is still yours to change.

There is no bulk edit. No selecting forty records and setting a field across all of them, no mass reassignment of owner, no bulk delete. Changes are made one record at a time, which is slower and is the point: the operations people ask for here are the ones whose mistakes surface a fortnight later and cannot be traced back to a single action. The nearest thing to it is an import, which will fill a field that is empty on a record it matched, and which you approved a preview of first.

Consent is written down rather than collected. The product records what somebody agreed to, when, on which channel, on what basis and in what words, and shows you that history rather than a tick box. It does not go and obtain the agreement for you. There is no double opt in and no confirmation email, and a form on your website will not alter the consent position of somebody who already has a record here, because nothing on that form establishes who filled it in.

Duplicates are found and never prevented. Nothing stops the second copy being created. The check that matches on a name reads the most recent five thousand records you are allowed to see rather than every one of them, so in a very large database a near duplicate name can pass unnoticed; a matching email address has no such ceiling. Neither of them joins anything up for you, for the reason given further up this page.

A recruitment agency holds two populations who turn into each other, because the candidate placed this year is the hiring client in three. A letting or estate agent holds applicants, landlords and tenancies against the same property. Membership organisations hold corporate members with named individuals inside them, and professional firms hold the referrer who is not the client. Every one of those is a person and an organisation at once, which is the case the contacts and companies split cannot describe.

The parts of the product this page leans on are import, export and search for getting the records in, permissions and the audit trail for ownership and sensitivity, and marketing for the consent check at the moment of sending.