Connecting other systems

The usual approach to integration is synchronisation: a copy of someone else's data is brought into your system and kept roughly current by a process that runs periodically. It is the obvious design and it has a failure mode that is guaranteed rather than likely.

Two copies of the same fact will disagree. The synchronisation fails quietly, or runs late, or hits a rate limit, or succeeds while the other system is mid update. Now one of the numbers is wrong and neither system knows which. The discovery is always the same: a customer, an auditor or a year end.

The alternative is to read the value at the moment someone looks at it. There is one authority for each fact, and the question of which copy is right cannot arise because there is only one. When the connection is broken the value is absent and the product says so, which is a considerably better failure than a stale number displayed confidently.

Which is also why some things are deliberately absent

This principle is the reason Consonas does not do accounting. Cost, headcount and the ledger belong to the system that owns them. Copying them here would create a second authority for numbers that must only have one, and building our own would create a second, worse general ledger.

The same reasoning applies to product usage in a technology business, to stock in a retail one and to valuations in an advice firm. In each case there is a system whose job that is, and the right relationship is to read from it.

What connects today

Mailboxes, calendars, web forms, outbound events, and the public sources. That is the list. It is shorter than the marketplace of any established competitor by a very large margin, and the most asked for connection we have not built, the accounting platforms, is named and still an export.

Why we are not racing to lengthen it

Because a connector is an ongoing commitment instead of a piece of work that finishes. The other system's interface changes. Their authentication moves. Their rate limits tighten. A connector nobody maintains becomes a connector that fails, usually quietly, and a failed integration is worse than an absent one because someone is relying on it.

Ten connections that are maintained are worth more than sixty that mostly work, and a company of our size can maintain ten. Claiming sixty would be a marketing decision rather than an engineering one.

If yours is missing

Tell us, and describe what needs to move between the two systems rather than just naming the product. Whether it is a fortnight or a quarter depends entirely on that, and the requests that describe the actual problem are the ones that get built first, because they are the ones we can size.

What is not built

No accounting connector, which is the most asked for one we have not built. No replay of an outbound delivery that has run out of attempts. No published integration with the automation platforms that connect everything to everything, though the API is usable from any of them. No marketplace, no partner built connectors and no way for anyone outside to submit one, which is a real advantage the incumbents have and one we are not going to pretend away.

Decide which system owns each fact

Before connecting anything. Who owns the customer's address, the invoice total, the appointment? One system owns each, and the other reads it. Two systems that both believe they own a fact will diverge, and they will diverge silently.

In most small organisations the answer is straightforward once it is asked out loud: the accounting system owns money, the calendar owns time, and this owns the relationship.

Connect one thing and leave it a week

Connections are the part of any system most likely to surprise you, because they involve someone else's product changing without warning. One at a time, with a week between, makes the cause of any surprise obvious.

Understand what a revocation does and does not do

Revoking a connection stops anything further. It does not remove what has already been brought across, and it should not: the history is part of your record now.

Expect the list to be short

It is shorter than the established competitors and that is a genuine disadvantage rather than a philosophy. If the system you need is missing, saying so is the fastest way to move it up, because at our size the order is genuinely decided by what people say is stopping them.

Mailboxes, and only your own, on the Inbox screen

A connected mailbox shows five things: the address, which provider it came through, how many messages have been taken onto records, how many were looked at and left alone, and whether it is connected or has stopped with an error. Two actions sit beside it. Look now, which asks the provider for anything since the last cursor, and disconnect.

The list is scoped to the person asking, always. Colleagues cannot see which of your mailboxes are connected and cannot disconnect one, because a connected mailbox is somebody's own account rather than organisation information. The asymmetry is deliberate and it is worth stating in full: the correspondence that comes out of a mailbox belongs to the organisation, and the account it came through does not.

The two counts are the honest part of that row. A mailbox that has taken forty messages and left eleven hundred alone is behaving exactly as intended, because most of what is in anyone's mailbox is not correspondence with a customer. A screen that showed only what had been taken would be hiding the more interesting number.

Where whoever runs the deployment has not registered an application with Google or Microsoft, the screen says so in those words and offers no button. A button that fails teaches someone that the product is broken. A sentence explaining that this is a step for whoever runs Consonas rather than for them teaches them who to ask.

Keys for other systems

A key row carries what it is for, the role it was issued with, who issued it and when, and the date it was last used or the word never. Never, on a key issued four months ago, is the most useful thing on this screen. It is either a job that quietly stopped running or a credential nobody needs, and both of those are worth knowing.

Issuing one asks two questions. What is it for, which is required, because an unlabelled key is one that nobody dares revoke in two years' time. And which role, where the offered answers are read only and standard, with read only the default. A key carries a role instead of a person, so it can do exactly what somebody with that role could do and nothing beyond it.

The key itself is shown once, on the screen that created it, with a line saying to copy it now. Only a hash of it is kept, so there is no version of this product in which anyone can show it to you again, including us. It begins with a short prefix so that someone who finds one in a log file or a repository can recognise what they are looking at and tell you.

Addresses to tell

The next card is addresses of yours that we post to when something happens. Each row shows the address, which events it asked for, and its state: listening, or the reason it was switched off written out as a sentence rather than as a code. Adding one produces a signing secret, shown once, for the same reason a key is.

Behind each subscription is the delivery log: the recent attempts, with the event, how many attempts have been made, when the next one is due, what status came back and what the error said. That log exists so that the question of why an endpoint is not hearing anything has an answer inside the product instead of being a conversation with support.

What is deliberately not on this screen

A subscription's signing secret is not among the columns the list asks the database for. It is not hidden by the interface, which is a weaker thing: the query that draws this screen cannot return it at all.

Mailbox credentials are held in their own table, and that table is excluded from export by name. An export is a file a customer downloads, and a file containing a live mailbox credential is a breach waiting to be forwarded to someone.

The person whose mailbox it was has left

Disconnecting removes the mailbox and its stored credentials. The messages already taken stay exactly where they are, on the customer records they concern, because they are the organisation's correspondence and not the mailbox's property. This is the one place where a connection is deliberately not symmetrical: removing the pipe does not remove what came through it, and it should not.

A reply sent from here lands in the sender's own sent folder

It does, every time, and without care it would appear on the record twice. Two identifiers are compared instead of one. The provider's own identifier catches the same message seen twice by the same sync, and the message identifier catches the same message arriving by two different routes. The second of those is the case that actually happens all day.

Something in the mailbox involves no one you hold a record for

It is left alone and counted. A message has to involve someone the organisation already has a record for before any of it comes across, and messages entirely between machine addresses, the noreply and postmaster sort, are left alone as well. Anything older than the window set when the mailbox was connected, thirty days unless somebody chose otherwise, is left alone too. Connecting a mailbox should not drag ten years of correspondence into a record nobody asked to have filled.

Your endpoint answers politely and does nothing

We cannot tell, and neither can anybody else. A status in the two hundreds is the only signal a receiver gives, and a receiver that acknowledges a delivery and then drops it is indistinguishable from one that processed it. The delivery log will show a clean run of successes. This is a genuine limit of the mechanism rather than of this implementation, and the only defence at your end is to record what you received.

A delivery arrives about a record that has since been deleted

The payload is a description of what happened at the moment it happened, not a promise that the record still exists in that state when you read it. Anything that matters should be read back through the API rather than trusted from the body of a delivery that may have been waiting an hour to be accepted.

You are already at your allowance of connected systems

Mailboxes and active subscriptions both count against the same allowance, and the count is made when you add one. Existing connections are not touched when a plan changes; the next one you try to add is refused, and the refusal names the plan that would allow it rather than saying that permission was denied. Those two answers send an administrator to completely different places, and only one of them exists.

A key ends up somewhere it should not

Revoking is immediate and is scoped by organisation as well as by identifier, so nobody can revoke another organisation's key by guessing at one. The prefix on every key exists for this moment: someone scanning a repository or a log can tell what they have found and say so.

The uncomfortable part is the one nobody asks about. A key carries a role, not a person, so it does not stop working when the person who issued it leaves. Removing someone from the organisation is therefore not the whole of removing their access until somebody has also read down the list of keys, which is why the list shows who issued each one and when it was last used.

A company number that was fine last year

Company details are read from Companies House on a schedule and cached, never fetched while somebody waits for a page, because the published rate limit works out at about two requests a second for a whole deployment. So a company that changed status this morning may show yesterday's status this afternoon. A rate limited answer is recorded as its own outcome rather than being treated as a company that does not exist, because those two look identical to careless code and mean opposite things.

The three permissions

Connecting a mailbox is a permission held by managers, standard users and restricted users, scoped to their own, which is why the list only ever shows your own mailboxes. The read only role does not hold it at all: someone who can see everything and change nothing has no business attaching an account to the organisation.

Managing the addresses we tell is a separate permission, held by owners and administrators. Issuing and revoking keys sits under administering the organisation, held by the same two. The separation is deliberate. Attaching your own mailbox is a personal act, and the worst it can do is limited to one account. Issuing a credential that acts with a role across the whole organisation is not, and the two should not be reachable by the same people simply because they appear on one screen.

What each plan allows

Systems connected: one on the free plan, two on Starter, ten on Standard, and no ceiling above that. Mailboxes and active outbound subscriptions both count against it, because both are a live connection between this and something else, and a ceiling that counted only one of them would be a ceiling somebody could walk around.

The public API begins at Starter. A free organisation cannot issue a key at all, and the refusal names the plan that would allow it. Call allowances are ten thousand a month on Starter, a hundred thousand on Standard, a million on Professional, and negotiated above that, summed across every key the organisation holds.

Connecting a mailbox needs Standard, because it belongs to the shared inbox and email integration. Web forms feeding leads need Standard as well. Companies House details, the VAT check and the bank holiday dates are read by the product itself rather than connected by an organisation, so there is nothing to connect and nothing to buy.

What no plan changes

Every act on this screen is written to the audit trail on every plan, including the free one: a mailbox connected and by whom, a subscription created or removed, a key issued or revoked, and a form submitted by a visitor with the name and address they typed. The audit trail, consent records, subject access tooling, two factor sign in and complete export are on every plan permanently and are never sold as an upgrade.

Consent captured through a web form is recorded with the exact wording the visitor was shown, not as a tick. What was agreed, when, and in what words is the thing that has to be produced if anybody ever asks, and a box with a tick in it cannot produce it.

The part that reads badly and is true

The free plan allows one connected system, counted across mailboxes, calendars and outbound subscriptions together rather than one of each. On Free that one connection can now be a calendar, which is the thing most people wanted it to be. Mailboxes still need Standard, outbound events need the API allowance that starts at Starter, and accounting is still an export rather than a connection. That is an honest description of where the product is rather than a plan design anyone would defend.

The trades that ask about this first

Which system owns which fact is a different question in every trade. Technology asks about product usage, retail services asks about stock, financial services asks which system holds the valuations, because this one does not, and professional services asks about the accounting package the practice already runs. Those pages say what is read and what is kept here.