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.
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