Request a discovery call
  1. Home
  2. What we build
  3. Connected Operations
  4. Integrations and data

Connected Operations

Integrationsand data.

System integration connects the systems you run, such as your CRM, ERP, accounting and e-commerce, so an order, a lead or a payment appears everywhere it is needed without a person carrying it across.

A written map of which system is right about what, and an alert to a named person when two of them disagree.

Request a discovery call Start with an audit

Soundslike this?

  1. Somebody exports a file out of one system every Monday and imports it into another.

  2. Our sales team retypes inquiries into the CRM out of an inbox.

  3. The stock number on the website is a number a person updates by hand, when they remember.

  4. Two systems disagree about a price, and there is an argument about which one is right.

  5. Month end takes a week, and most of that week is reconciling.

  6. We are buying a new system, and nobody has written down what it has to fit into.

  7. When a transfer fails, we hear about it from a customer.

If none of those is familiar and the real problem is that work sits in a queue until somebody gets to it, the connection is not the missing piece and Agentic Operating Systems is the page for that.

CRM and system integration, in plain language.

What happens today

An order is placed on the website. Somebody opens the order, opens the accounting package, and types it in again. On Monday a file comes out of the warehouse system and goes into a spreadsheet, and the spreadsheet decides what the website says about stock until next Monday.

Nothing here is broken, exactly. Five systems each hold part of the truth and a person carries the rest between them. The business is running on somebody's memory of which screen to trust.

What happens after

The order placed on the site appears in the accounting package with the same identifier it has everywhere else. The lead from the form arrives in the CRM with its source and its owner.

The payment reconciles. Stock on the website is stock in the warehouse, and it is that at four in the afternoon as well as at nine in the morning.

When two systems disagree, nothing is silently overwritten. It stops, a named person is told, and the decision they make is recorded. The exception is a queue rather than a discovery.

Most businesses do not have a software problem. They have a translation problem.

Five systems each hold part of the truth, and somebody exports from one and pastes into another every week. Integration work removes that person from the middle, and it starts with a question rather than with code: which system is right about which field.

Most integration problems are really that question left unanswered, and a connection built before it is answered does not settle the argument, it encodes it.

The unglamorous part is where the value is: what happens when a system is down, when a record is a duplicate, when a field is empty, when two systems disagree. We design those cases deliberately, because an integration that only works on a good day creates more work than it removes.

Who this is for, and who it is not for.

Where this pays for itself

  • Somebody exports and imports on a schedule, and everybody knows whose job it is and which day it happens.
  • Three or more systems hold overlapping records, and none of them is agreed to be the one that is right.
  • The website should show real stock and real pricing, which for a distributor or a manufacturer is the difference between a catalogue and a shop.
  • Inquiries are retyped into the CRM, which is also where the source and the owner quietly disappear.
  • A new system is being bought, and what it has to fit into has not been written down yet.
  • A number has to be explained to a board, an auditor or a customer, and today the explanation is a person's recollection.

You probably do not need this if

  • Two mainstream systems already have a supported connection between them. Turn it on. It is usually configuration rather than a build, and paying anybody to rebuild it is paying twice.
  • It is a handful of records a month. Ten minutes of somebody's time once a month costs less than anything we would build, and it does not need monitoring.
  • Nobody can say which system owns a field. That decision is the project. Until it is made, a layer built over the disagreement makes the disagreement automatic and much harder to see.
  • One of the systems is being replaced this year. Connecting the one that is leaving is work with a known expiry date, and waiting is usually the cheaper plan.
  • The requirement is a single dashboard rather than connected systems. That is reporting, it reads rather than writes, and it is a smaller job than this one.

Where an automation tool does the job, we will say so, and we use them ourselves where they fit.

What it includes.

Fifteen capabilities, what each one does in plain words, and what it changes for the business. The first group is the one people try to skip, and it is the one that decides whether the rest of it works.

None of the three headings is a link, because the pages beneath this service have not been written yet and a heading that promises one is a heading that lies.

Integrations and data, the capability table
Capability What it does What it changes
Decide the truthBefore any connection is built
System inventory What you run, by name and version, who owns each one internally, and what each is the truth for. The argument about which screen is right happens once, in a room, instead of again and again.
The direction of truth Which system owns which field, agreed and written down before anything is connected. An overwrite is a rule somebody chose rather than an accident somebody discovers.
Connection assessment What each system's interface actually allows, what it costs, and where its limits are, including the old and locked-down ones. The unpleasant surprise happens during scoping, which is the only phase where it is cheap.
Mapping and matching rules Fields, identifiers, and the rule that decides when two records are the same record. The same customer stops existing three times under slightly different names.
Build the connectionsOne at a time, proven before the next
Synchronization design Real time, scheduled or on demand, chosen per connection with the reasoning written beside it. You are not paying for live updates on a field that changes twice a year.
The connections themselves Built one at a time, proven in a test environment, then live, then the next one. A failure is traceable to one connection instead of to a launch.
Error handling Retries, queues, alerts, and what a person sees and does when something cannot be resolved automatically. The integration still behaves on the day one system is down.
Duplicate and conflict rules What happens when two systems disagree, and which disagreements stop for a person instead of resolving quietly. Nothing important is overwritten by whichever system wrote last.
Historical migration Where the connection also needs the past, moved once, checked, and reconciled against the source. Reporting works across the join instead of starting from the day you switched on.
The test environment A place changes are proven before they touch live data, kept after launch rather than dismantled. The next change is also safe, which is the part that pays for it.
Run themAfter launch, because a connection is not a delivery
Monitoring Every connection watched, with alerts pointing at a named person rather than at a shared inbox. You hear about a failure from us rather than from a customer.
The transfer record A record of what moved, when, and what happened to it, kept for the times a number has to be explained. An awkward question has an answer that is not somebody's recollection.
The exception queue The screen a person works in when a transfer stopped, showing what stopped and why. The unresolved cases are a short list rather than a silence.
Documentation per connection What it does, what it maps, what it retries, written for whoever maintains it next. A developer who has never met us can pick it up.
Volume and failure reporting A regular written report: what moved, what failed, what was resolved by a person, and what changed since the last one. The connections stop being invisible until the day they break.

Scroll the table sideways to read it.

How it works.

Almost everything on this board is already yours. One plate in the middle is the work, one line near the bottom is the part that stays with a person, and the route across the top is the one that stops.

Scroll the drawing sideways to read it.

Nine systems, one layer, and one broken line across the top. The break is the deliverable.

What the system does

The work, the path it takes, and everything HUREAL builds. It never means anything else.

What stays with a person

The line, its single opening, and the plate standing in it. On a light board it is the one dark plate.

What you already run

Present, named, and not for sale. The lowest contrast on the board, deliberately.

  1. Everything on the board except one plate is already yours.

    Your website, your app and your store on one side. Your CRM, ERP, accounting, booking, marketing and analytics on the other. They are drawn in the quietest tone on the board on purpose: this service does not replace any of them, and a proposal that starts by replacing three of them is a migration wearing an integration's name.

  2. The route across the top is the one that stops.

    It is drawn, and then it is cut. That route is a person exporting from one system and pasting into another on a schedule, and it is the thing you are actually buying the end of. It is also the only line on the board that nobody designed.

  3. One layer, and one direction per field.

    The plate in the middle is the whole build. It holds the map: which system owns price, which owns stock, which owns the customer's address, and what happens to the other copies when the owner changes. That map is agreed in phase one, in a room, before a line of it is built.

  4. What crosses, and how often, is a decision per connection.

    Every arrow carries what moves and on what cadence. Real time where a customer is waiting for it, scheduled where nobody is, on demand where it is expensive. Choosing live updates everywhere is how an integration becomes costly and fragile at the same time.

  5. When two systems disagree, it stops at the line.

    Retry, queue, alert to a named person, and a queue that person actually works in. Nothing important is resolved by whichever system happened to write last, and every resolution is in the transfer record, which is what makes a number explainable later.

Bring the list, by name and version. Which systems you run, who owns each one internally, and which screen your team trusts when two of them disagree. That list plus a discovery call is the whole of phase one, and the map that comes out of it is yours whether or not you build anything.

Request a discovery call

What you end up with.

  • The system inventory

    Every system by name and version, what it is the truth for, who owns it internally, and what its interface actually allows.

  • The direction of truth

    Which system owns which field, written down and agreed, which is the document the whole build is measured against.

  • The field map

    Fields, identifiers and matching rules per connection, including what counts as the same record.

  • The connections

    Built one at a time, each proven in a test environment before it touched live data.

  • The failure design

    Retries, queues, alerts and the human path, written as a document rather than left as behaviour to be discovered.

  • The exception queue

    The screen a person works in when something stopped, showing what stopped, why, and what happens if they do nothing.

  • The transfer record

    What moved, when, and what happened to it, kept for the times a number has to be explained to somebody.

  • Monitoring and alerts

    Live before launch day, pointing at a named person rather than at a dashboard nobody opens.

  • Documentation per connection

    Written for a developer who has never met us, because being difficult to replace is not a business model we are interested in.

  • The test environment

    Kept after launch rather than dismantled, so the next change is as safe as the first one was.

V3. The direction of truth, drawn

your-company/integration/field-map 6 fields, 1 unowned

Which system is right about what

Agreed in phase one. Every connection is built to this and nothing is built before it.

  • List priceOwner: the ERP

    Read by the store and the CRM, written by neither. A price changed anywhere else is rejected and the attempt is in the record.

    One way
  • Stock on handOwner: the warehouse system

    Pushed to the store every few minutes, and the store shows the time it was last true rather than implying it is live.

    One way
  • The customer recordOwner: the CRM

    Created wherever the customer first appears, then owned by the CRM. The identifier it is given there travels with it everywhere else.

    One way
  • The orderOwner: shared, in sequence

    Created by the store, owned by the ERP from the moment it is accepted. The handover point is a line in this document rather than a convention.

    Two way
  • Payment statusOwner: the accounting package

    Nothing else may mark an invoice paid. The store is told, and the store does not decide.

    One way
  • The delivery addressOwner: not decided

    Three systems write it and none of them is agreed to be right. It stops here until somebody on your side decides, and nothing is built over it in the meantime.

    Unowned
Every one of these documents has a row like the last one, and finding it is most of the value of phase one. A connection built over an unowned field does not settle the argument about it. It makes the argument automatic, and much harder to see.

The connection layer, its code and its logs run in your own accounts from day one. How ownership works

Discover, design, build, launch, improve. Scope, price and timing are agreed before implementation. See the full process

What it connects to.

By category, because the category is the question. On this service the honest answer is a list plus a qualifier, and the qualifier matters more here than anywhere else on the site: an old system connects through whatever door it has, and sometimes that door is a scheduled file.

  • CRM

    Where the customer record, the source and the owner live, and usually where the identifier everything else refers to is created.

    Salesforce, HubSpot, Zoho, Dynamics

  • ERP and accounting

    Where price, cost, credit, invoices and stock are true, which is why it is usually the owner of more fields than anything else.

    NetSuite, SAP, Sage, QuickBooks

  • E-commerce

    Where the order starts, and where the catalogue has to agree with whatever the warehouse thinks.

    Shopify, WooCommerce, BigCommerce

  • Booking and scheduling

    Where a slot or a job is held, moved or released, and where a double booking is the failure everybody notices.

    Calendly, Acuity, an in-house dispatch board

  • Marketing and email

    Where a contact is sent something, which means consent has to travel with the record rather than be assumed at the other end.

    Mailchimp, Klaviyo, HubSpot

  • Analytics and reporting

    Where the numbers are read, which is the one direction where a copy of the data is usually the right answer.

    a warehouse, a reporting database, your existing analytics

  • Payments

    Where money moves, and where reconciliation either happens automatically or happens on somebody's Friday.

    card processors, Interac, your bank's file formats

  • Documents and storage

    Where the signed thing, the drawing or the certificate lives, which is often the attachment a record is useless without.

    SharePoint, Google Drive, Dropbox

  • Your industry system

    The one system that runs your trade. It is usually the oldest, the most important, and the hardest to connect.

    dispatch, estimating, practice management, warehouse management

Every connection is validated by HUREAL's engineers during scoping and confirmed in writing before signature. Where a system genuinely cannot be connected, you hear it during discovery rather than during the build, and the scope is drawn around it instead of making a platform migration the price of entry.

What we do, and what we will not do.

What we do

  • Answer the question firstWhich system owns which field, written down and agreed, before a connection is built.
  • Check every doorEach system by name and version, and what its interface actually allows, confirmed in writing during scoping.
  • Design the bad dayRetries, queues, alerts and the human path, specified before the good day is built.
  • Build one connection at a timeProven in a test environment, then live, then the next, so a failure has an address.
  • Alert a personEvery failure points at a named human being rather than at a shared inbox or a dashboard.
  • Keep the recordWhat moved, when, and what happened to it, so a number can be explained months later.
  • Document for the next developerWritten for somebody who has never met us, because being hard to replace is not a business model we want.

What we will not do

  • Build over an unowned fieldWhere nobody will say which system is right, we stop and say so. A layer over a disagreement automates the disagreement.
  • Rebuild a connection that already existsWhere two systems have a supported connection, turn it on. Charging to rebuild it is charging twice.
  • Let a failure be silentNo retry loop that gives up quietly. If it cannot be resolved, it queues and somebody is told.
  • Make a migration the price of entryWhere a system is hard to connect, the scope is drawn around it. Replacing your software is not our opening offer.
  • Move data nobody needsEvery field that crosses a connection has a reason to be there, and the ones that do not are left where they are.
  • Ship without a test environmentIf there is nowhere to prove a change before it touches live data, that is the first thing we build.
  • Sell a layer where ten minutes a month would doAt a handful of records, a person is cheaper than anything we would build and needs no monitoring.

A person, a wiring tool, or a layer.

Three ways to get a record out of one system and into another. They cost different amounts, they fail differently, and two of the three are often the right answer.

The three approaches, on ten deciding factors
Deciding factor A person and a spreadsheetManual An automation tool, wired point to pointSubscribed A built integration layerBuilt
Cost to start Nothing. It is already happening. Low. A subscription and an afternoon. Highest. It is a build, and the first phase is a decision rather than code.
Cost to keep The same hours every week, forever, and they are somebody's Monday. A subscription that usually rises with the number of operations. Hosting, plus ongoing support if you want it. Both declinable.
What happens as volume grows The hours grow with it, in a straight line. Cost and fragility both grow with it, and the fragility arrives first. Volume is the part that does not cost more.
When one system is down The person notices, and does it later. It depends on the tool, and a quiet failure is common. It retries, then it queues, then it tells a named person.
A record that does not match Judgement, applied consistently and written down nowhere. A second record, usually discovered later by somebody else. Matching rules you agreed, and an exception queue for the rest.
Who knows how it works One person, and it leaves with them. Whoever built the scenario, if they still work there. A document written for a developer who has never met us.
Adding the fourth system Another routine on the same person's Monday. More wires between more pairs, which is where the count multiplies. One more connection to a map that already exists.
Explaining a number six months later Recollection. Partial logs, kept for as long as the plan keeps them. The transfer record: what moved, when, and what happened to it.
Where it lives A shared drive. The tool provider's account, on the provider's terms. Your own cloud accounts.
When it is the right answer A handful of records a month, and nobody is waiting on them. One or two connections, modest volume, two mainstream systems, simple matching. Three or more systems overlap, the volume is real, and somebody has to be able to explain a number.

Which one to choose

If it is a handful of records a month, keep the person. Ten minutes on a Monday costs less than anything we would build, it needs no monitoring, and automating it would be buying a system to save a number of minutes you could count on one hand.

If it is one or two connections between mainstream systems at modest volume, buy the automation tool. They are good at exactly that, we use them ourselves where they fit, and paying for a build to get it is paying twice.

They get fragile with volume, with complicated matching, and when nobody owns them, which is the point at which this conversation is worth having again.

A built layer earns its cost in a narrow place: three or more systems hold overlapping records, the volume is real, a failure costs money or a customer, and somebody has to be able to explain a number to a board or an auditor.

That is the whole case. The discovery call is where we find out whether you are in it, and the inventory that comes out of it is useful to you either way.

Designed around the markets you serve.

An integration moves personal information between systems that were each chosen for a different reason, sometimes into a different country, usually without anybody watching it happen. We identify privacy, accessibility, data-location, and operational requirements during discovery, based on where your business operates and what the system handles.

Technical controls and documentation are agreed with your team and legal advisers where needed. For a business operating in Canada, these are the requirements that usually apply.

  • Where the data livesAnd which processor sees it, which on this service is the first question rather than the last

    What we design forThe region every connection runs in and every queue is held in, named in the scope before the build. Where a transfer crosses a border because a system you already run lives there, that crossing is a decision on a page rather than a side effect of a default.

    What we document for your counselEach connection, each processor it passes through, the region it passes through, what it carries, and what changes if you move a system later.

  • PrivacyPIPEDA, and Quebec's Law 25 where it applies

    What we design forThe smallest set of fields that does the job, per connection. A stated purpose for every field that crosses. Retention on the queues and the transfer record set deliberately rather than left at a default, and no copy of a personal record kept in a place nobody listed.

    What we document for your counselWhat each connection carries, where copies come to rest, who can reach them, and how long they are kept, so a request about one person can be answered across all of it rather than in one system at a time.

  • Health informationWhere a connection touches it at all

    What we design forNo health information in a connection until the storage region and the handling are settled. Where they are not settled, the connection is scoped to exclude it rather than scoped around it.

    What we document for your counselWhich data classes were excluded and why, so the boundary is something your privacy officer reads rather than infers.

  • Electronic messagesCASL, wherever a connection feeds a marketing system

    What we design forConsent and its basis travelling with the record rather than being assumed at the far end. A contact that arrives in a sending tool without a consent basis does not arrive at all, and an unsubscribe recorded anywhere is honoured everywhere.

    What we document for your counselWhich connections can add somebody to a sending list, what consent basis each one requires, and the transfer record that shows what actually moved.

  • AccessibilityWCAG 2.2 AA, plus AODA, the provincial equivalents and the Accessible Canada Act where they apply

    What we design forEvery surface a person actually uses, which on this service means the exception queue, the mapping screens and the alerts. Keyboard, screen reader, contrast and reduced motion, tested rather than asserted, because an internal tool is somebody's whole working day.

    What we document for your counselThe test results per surface and the standard tested against, so a barrier report can be answered with a measurement.

  • Records you have to be able to produceFinancial, tax and sector record keeping, whichever apply to you

    What we design forA transfer record that survives the systems it describes: what moved, when, in which direction, what failed, and what a person decided. Kept for a period you set rather than for as long as a log rotation happens to keep it.

    What we document for your counselWhat the record contains, where it is held, how long it is kept, and how to export it, so the retention period is your decision and not an accident of configuration.

HUREAL designs to a standard, tests against it, and documents what was built. The determination is your counsel's or your privacy officer's to make. Our own conformance target and how to report a barrier are on the accessibility page.

Questions people actually ask.

  • Our ERP is old. Can it be connected?

    Often, and the honest answer needs its name and version. Older systems connect through whatever door they have, which is sometimes a modern interface and sometimes a scheduled file exchange. We check before scoping and tell you what is involved, because this is exactly where unpleasant surprises live.

  • Should we just use an automation tool?

    Sometimes, and we will tell you when. Those tools are good at simple, low-volume connections and we use them where they fit. They get fragile with volume, with complex matching rules, and when nobody owns them, which is the point at which a built connection is cheaper and calmer.

  • Who fixes it when it breaks?

    We do, under ongoing support, and you can see it break because monitoring alerts a person rather than failing silently. The documentation is written so that another developer could also fix it, which is the point.

  • What does it cost?

    The price is set after the discovery call and written into the proposal you sign. How scope and price are set

  • What if two systems disagree about a customer?

    That is decided in phase one, not by whichever system wrote last. Each field gets an owner, and the disagreements that matter stop in an exception queue for a person instead of resolving quietly. Where nobody will name an owner, we stop and say so rather than building over it.

  • Will this slow our systems down?

    It should not, and the cadence is how that is controlled. Real time where somebody is waiting, scheduled where nobody is, on demand where a call is expensive. Choosing live updates for everything is the usual cause of both a large bill and a fragile connection.

  • Do we have to move our data anywhere?

    No. The systems stay where they are and the records stay in them. What moves is the specific fields a connection carries, and the region every one of those passes through is named in the scope before the build rather than inherited from a provider default.

  • Can you migrate our history as well as connect us?

    Yes, and it is scoped separately, because a migration is a different job from a connection. It moves once, is reconciled against the source, and is checked by somebody on your side before the old system is switched off. Reporting that works across the join is usually the reason to do it.

  • How do we know a transfer actually happened?

    The transfer record. What moved, when, in which direction, what failed and what a person decided, kept for a period you set. It is a deliverable rather than a debug file, because the day you need it you will be explaining a number to somebody who is not technical.

  • What happens when one of our vendors changes their interface?

    It is handled under ongoing support, and it happens on their schedule rather than yours. Monitoring catches the break, the alert points at a person, and the exception queue holds whatever was in flight so nothing is lost while the connection is repaired.

Three services next to this one.

Where this matters most.

Four sectors, and the reason in each

  • Manufacturing and distribution

    Stock, cost, account pricing and credit live in a system that was chosen for the warehouse rather than for the website, and every quote is somebody checking two screens. This is the sector where the direction of truth document pays for itself fastest.

  • Construction and trades

    The estimate, the job, the purchase order and the invoice usually live in four places, and the same job number means something slightly different in each. Reconciliation is a person, and that person is normally the one who can least be spared.

  • Professional services

    Intake, matter management, time and billing were bought in different decades, and the client exists three times with three spellings. Matching rules are the whole project here, and getting them wrong is worse than doing nothing.

  • Real estate and property

    Listings, availability, maintenance and accounting change faster than anybody maintains by hand, and the number a tenant or a buyer sees is judged on whether it is true today rather than on where it came from.

Read on this topic

Every article about this service lives under one index, so a reader who wants depth has one place to go rather than a tag cloud.

The integrations and data index

Everything we have published on this

Not sure which process to start with? The Workflow Opportunity Sprint maps one workflow and defines what to build next.

Two ways to start from here.

I know what I need to build.

Discovery call

A free conversation, then a written proposal with scope, price, and timing.

Request a discovery call

One process creates too much manual work.

Workflow Opportunity Sprint

We map it, then define what a connected system should do next.

Explore the Sprint

Systems that agree, without a person maintaining the agreement.