Skip to main content
Some records aren’t yours to model. People, Organizations and Calendar are core apps provided to every workspace. They’re not in your repository, so you won’t find them by reading files.
That lists them along with their entity keys.

​
Check before you declare

Before you add an entity, ask whether it already exists. A company, a customer, a supplier, an employee, a calendar event: each of those already has a canonical record.
A second copy of Organizations is the one mistake this layout can’t undo for you later. Anything else you can add and remove. Two competing sources of truth for who your customers are will outlive the decision that created them.

​
Pointing at one

An ordinary reference field with targetApp set:
Nothing about this needs an instance, an account or a login. It resolves offline, and cordango check validates it offline.

​
The key isn’t the label

This gives you the entity key, the label, and every field the core app already carries. They differ more often than you’d expect: Organizations calls organization a “Company”. Look before you point. A reference to a key that doesn’t exist is a cordango check error. A reference to the wrong key of the right app isn’t, and that’s the one you find out about later.
Platform features need a Cordango workspace. Sign up here and create one in a few minutes.

​
Why they matter

Core apps are what make a workspace a company system instead of a folder of unrelated applications. Two apps that both reference core_organizations are talking about the same company, and that’s what lets a record in one app mean something in the other. Cordango Platform provides that resolution. A standalone generated application gets its own built-in directory instead, emitted as part of its runtime. A shared record is the cheapest of three ways apps work together. You can also point a reference straight at another app’s entity, or react to what it announces — see Apps working together.