# One company platform underneath every capability > Cordango capabilities share one company foundation: the same organizations, people, teams, permissions, audit history and automation. Nothing is integrated later because nothing was ever separate. Source: https://www.cordango.com/platform/ Language: en PLATFORM # One platform underneath all of it. 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. [See Cordango in action →](https://www.cordango.com/contact/) [How it is put together →](https://www.cordango.com/platform/#layers) ## Four layers, in a fixed order. Everything Cordango does sits somewhere in this stack. Knowing where a thing belongs is most of understanding the product. FOUNDATIONS Organizations and People 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. Organizations People PLATFORM CONTEXT The plane it all runs 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. Teams Roles & permissions Identity Activity Audit history Automation CAPABILITIES Business functions on top 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. CRM Projects Support PTO Invoices Recruiting and more WORKSPACES What one person actually sees 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. Sales HR Delivery Management Self-service Capabilities and workspaces change often. The two layers underneath them do not, which is what keeps the whole thing coherent as it grows. ## Connected by default, not integrated later. 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. - SHARED Capabilities use shared records instead of synchronised copies - LIVE A cross-capability view reads live data, not last night’s extract - RBAC Permissions apply to the answer, so nobody sees past their access - EVENTS A change in one capability can trigger work in another [The same thing, asked in plain language →](https://www.cordango.com/ai/) Across the company Invoices + Support + Organizations \# one question, three capabilities > which customers have an overdue invoice and an open ticket? → Globex SE €4,200 · 9d overdue · 2 open tickets → Umbrella Co €1,150 · 3d overdue · 1 escalation ✔ no connector no sync job · no export ✔ your permissions applied before the answer is built ## What every capability inherits. None of this is configured per capability. It is the platform, so a capability you install on Tuesday already has it. IDENTITY #### One sign-in One account per person across every capability. Access granted once, and ended once when they leave. TEAMS #### Nested teams Your real structure, up to six levels. Access flows down the tree and never flows back up. RBAC #### Roles and permissions Per entity, per field and per command. A project lead can see a person without seeing their salary. AUDIT #### Field-level history Who changed what, when, on the record itself. You do not model an audit entity to get it. ACTIVITY #### Shared activity One history across capabilities, so a company’s timeline is not split across four tools. FLOW #### Automation When something changes, do something: notify, assign, update a record, call a webhook. VIEWS #### Personal views Anyone can build their own pages and filters over an app, share them, or fork someone else’s. HOME #### Cross-capability home Widgets that span capabilities, because they read one data plane rather than several. TENANT #### Tenant isolation Your data sits in its own database schema, enforced below the application, not by a WHERE clause. API #### REST and MCP Every capability is reachable programmatically, under the same permissions as a person. PORT #### Portable format An application is a document. It can be exported, versioned, moved and installed elsewhere. EU #### German hosting Run in German data centres, with the company owning its data and its applications. ## Four ways a capability arrives. 01 ### Use one from the catalogue 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. 02 ### Adapt it 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. 03 ### Describe a new one 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. 04 ### Have us build it 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. ## The application belongs to the company. 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. - OWN Company-owned, not owned by the person who built it - READ A definition a human can read and review before it goes live - MOVE Install, adapt, export and share without a rewrite - SAME A generated capability inherits the same governance as a catalogue one [Security and governance →](https://www.cordango.com/security/) Portable format sales-crm \# an application is a document > export sales-crm ✔ data model entities · fields · relationships ✔ screens pages · views · record surfaces ✔ behaviour commands · processes · automations ✔ roles who may do what → install elsewhere same definition · different company NEXT ## Bring one process that crosses several tools. The fastest way to see what a shared foundation actually buys you is to watch one of your own processes stop being three systems. [See Cordango in action →](https://www.cordango.com/contact/) [Start with Organizations →](https://www.cordango.com/organizations/) About 30 minutes, on a real company platform