Data & integration
Connecting the CMS to the systems around it: identity, CRM, ERP, reporting, so one source of truth feeds every screen.
We connect the platform to the systems around it: identity, CRM, ERP and reporting. Data is entered once, owned in one place, and correct everywhere it appears.
Talk about an integration- Single sign-on and identity
- CRM and ERP synchronization
- Reporting that reads from one source of truth
What integration work is for
Every institution has data that lives in several places at once: a person in the directory, the CRM and the CMS; a program in the catalog, the ERP and the website; a document in the records system and on a page. When those copies drift, people see the wrong thing and staff re-key it by hand. Integration is the work of deciding which system owns each fact, and building the connections that keep the others in step.
What we do with it
We connect Drupal to identity providers for single sign-on, with SAML or OpenID Connect, so staff and members log in once and permissions follow their role. We synchronize with CRM and ERP systems in both directions, on a schedule or by webhook, with the ownership of each field written down. We build and document APIs and feeds so other systems can read the content, and we connect the platform to the reporting warehouse so dashboards read from one source. Every connection is monitored, logged and re-runnable, because integrations fail quietly and are found late.
How we work
The first deliverable is a data map: what systems exist, what each one owns, what flows where and how often. Then each connection is built and tested against a copy of the real data, with the failure cases handled first: a record that vanished, a field that changed shape, a system that was down for an hour. Identity is done early, because permissions shape everything after. Nothing is synced by hand, and every sync leaves a log a person can read.
Why now
Platforms rebuilt for Drupal 11 ahead of the December 9, 2026 end of life for Drupal 10 are a chance to connect them properly rather than carry over a decade of one-off scripts. Identity providers, CRMs and ERPs now expose stable APIs, which makes the connections ordinary engineering. This is a Horizon service: we build these connections as part of platform work and offer them on their own where the fit is clear.
I want to …
let people log in once
Single sign-on with your identity provider, SAML or OpenID Connect, with Drupal roles assigned from the directory so permissions follow the person.
- Your identity provider, your rules for who gets what
- Roles mapped from directory groups, never assigned by hand
- Tested with real accounts before anyone is switched over
keep the CMS and the CRM in step
Contacts, organizations and relationships owned in the CRM and reflected on the platform, or the other way round, with ownership per field written down.
- A data map that says which system owns each fact
- Sync on a schedule or by webhook, in one or both directions
- Failures logged, alerted and re-runnable
publish records from the ERP
Programs, products, fees, schedules: held in the system of record, published on the platform without re-keying.
- Records pulled on a schedule, published through the content model
- Changes visible on the site within the window you set
- A page for every record that should have one, retired when the record is
report from one source of truth
Platform data delivered to the reporting warehouse so dashboards read from one place, and the questions leadership asks get one answer.
- Events and content data exported on a schedule
- A model the warehouse team agreed to
- Dashboards that answer the questions written down first
expose the content to other systems
An API or feed, documented and versioned, so the mobile app, the intranet or a partner reads the same content the site does.
- JSON:API or a purpose-built endpoint, documented
- Versioned so a change does not break a consumer
- Rate-limited, monitored, cached at the edge
From a data map to connections that run themselves
Identity first, then each connection, tested against real data with the failure cases handled before the happy path.
Integrations fail quietly and are found late. Every one we build leaves a log a person can read and a button to run it again.
Services that pair with this one
Integration is a content model, a cloud account and a plan. These are the services most often bought alongside.
-
Drupal development
New builds, major-version upgrades, module and theme work, and migrations from Drupal 7 onward. Every site we build is one we can keep patched, accessible and on a supported version for years, because that is the job after launch.
-
Cloud engineering
We design and run the cloud your platform lives on, in your own account, as code, with monitoring, patching and a monthly cost review in writing. We do not resell hosting, and everything we build is documented so the next engineer can run it.
-
Digital strategy
The decisions that make or break a platform come before any code: the content, its structure, who publishes it, and what gets measured. We make them with you, in writing, and stay through the build so they hold.
Tell us what needs to talk to what.
The systems, which one owns the data, and what goes wrong today. We come back with a data map and what the connections would take.
Talk about an integration