Cordango capabilities are not separate products that were later connected. They are built on one company foundation, with the same records, the same permissions and the same history. That is why there is nothing to integrate.
Everything Cordango does sits somewhere in this stack. Knowing where a thing belongs is most of understanding the product.
The shared records your company is actually made of. Every company you work with, every person you work with. These are not applications. They are the context everything else operates on.
Teams, permissions, relationships, activity, identity and audit. Shared by every foundation and every capability, so nobody configures access twice or reinvents a history table.
CRM adds pipeline to organizations. Absence adds requests to people. Each capability contributes to records that already exist rather than starting a database of its own.
Several capabilities presented as one job. Sales opens a sales workspace, a manager opens a manager workspace, and both are looking at the same company data through different windows.
Capabilities and workspaces change often. The two layers underneath them do not, which is what keeps the whole thing coherent as it grows.
The layer above is not an idea. It arrives as three applications the platform provisions into every workspace, before you install or build anything. You do not choose them and you cannot uninstall them, because everything else is built on top of them.
Every company you deal with, once, in whatever mix of roles they play. Cordango researches each one from its own website and files what it finds with how much to trust it, so the list stops being a list of names.
What the research finds →Everyone you work with, in one directory with the teams and reporting lines every other app reads. A new joiner exists once, and a leaver stops existing once.
How the person record works →Appointments, availability and a public booking link, on the people and companies that are already there. Not a foundation, and not a separate product either: a core app built on both.
How booking works →Organizations and People are the two shared RECORDS, and only those two. Calendar is a third core app that reads them. Keeping that distinction is what stops every capability from claiming to be a foundation.
Ask most companies to list customers with an overdue invoice and an open support ticket and you start a small project. Two exports, a spreadsheet, and a number that is wrong by Friday.
In Cordango that is not a question about integration. Invoices and Support both write to the same organization record, so the answer is a query, not a pipeline. There is nothing to connect because nothing was separate.
None of this is configured per capability. It is the platform, so a capability you install on Tuesday already has it.
One account per person across every capability. Access granted once, and ended once when they leave.
Your real structure, up to six levels. Access flows down the tree and never flows back up.
Per entity, per field and per command. A project lead can see a person without seeing their salary.
Who changed what, when, on the record itself. You do not model an audit entity to get it.
One history across capabilities, so a company’s timeline is not split across four tools.
When something changes, do something: notify, assign, update a record, call a webhook.
Anyone can build their own pages and filters over an app, share them, or fork someone else’s.
Widgets that span capabilities, because they read one data plane rather than several.
Your data sits in its own database schema, enforced below the application, not by a WHERE clause.
Every capability is reachable programmatically, under the same permissions as a person.
An application is a document. It can be exported, versioned, moved and installed elsewhere.
Run in German data centres, with the company owning its data and its applications.
Install a ready-made capability. It arrives working, on your organizations and your people, with permissions already applied. Not a starting point you have to finish.
Change the fields, the states, the approval rules and the screens. Use the standard version where it fits and change only the parts where your company is genuinely different.
Tell Cordango what you need in plain words. It asks a few questions about how you work and builds the capability, on the same foundation as everything else.
Some things are too involved to generate. Tell us what you need and we build it with you, and it still inherits the same foundation, permissions and governance.
However a capability arrives, it lands on the same platform, with the same records, permissions and audit trail as everything else you run. None of the four starts a new silo.
A Cordango application is a single definition covering its data model, its screens, its behaviour and its roles. That definition can be exported, reviewed, versioned and installed somewhere else without losing anything.
It matters for a duller reason than portability. It means an application is not trapped inside whoever built it. The person who created the holiday tracker can leave, and the holiday tracker is still the company’s, still governed, still maintainable.
The fastest way to see what a shared foundation actually buys you is to watch one of your own processes stop being three systems.
About 30 minutes, on a real company platform