How Magic connects
Connections that read first and ask for the least.
Magic is a set of connected products, not one database copied six times. The accounting system stays the financial source of record, the customer record is shared under permissions, and every connection asks for the access it needs and nothing more.
You can connect your accounting system and see your business before you buy any product.
The system of record stays
Magic reads; your ledger remains the source of truth.
Records keep their origin
Every imported value says which product produced it.
Connections are scoped
A connection grants what your role allows, and no more.
The model
Read-first, not rip-and-replace
Magic asks for read access to the accounting system and treats what it reads as evidence. Actuals, balances and posted invoices stay where they are. The accounting system remains the source of record, and Magic places operating context beside it rather than editing it.
From there, the products share one customer record. A contact, an account, an agreement or a call is stored once and read by each product under the permissions the viewer holds. Connecting a product is not an integration project: it is a permission and a view.
Connections are deliberately narrow. The onboarding step names the organisation that will be read, shows the access being requested and states what Magic will not do with it. A connection you did not grant is a connection Magic cannot use.
Existing connection settings stay where they are
The authenticated connection pages for Flodesk, Stripe and Twilio remain inside the app, where a workspace administrator manages them. This page explains the model; it does not replace those settings.
What connects
What connects, and how it works
Each connection has one job and a stated boundary. Nothing on this page needs an integration marketplace or a middleware project.
Accounting system (Xero)
A read-first connection to Xero for actuals, balances and posted documents. Magic names the organisation it reads and shows the mapping from your chart of accounts into plan lines, marking anything it guessed as needing review.
One customer record
Contacts, accounts, opportunities, conversations and agreements live in one record. Each product reads the parts its role permits instead of keeping a private copy.
Permissions
Access is checked server-side on every read. A page cannot grant access, and a permission denial says so plainly rather than showing an empty record.
Native history
What a product recorded itself: its own calls, its own campaigns, its own conversations, kept in full for that product.
Optional context
What another product can add when the workspace holds it and the viewer is permitted: the customer's commercial picture beside the conversation, labelled by source.
Existing connection settings
The Flodesk, Stripe and Twilio connection pages remain authenticated app settings. They are managed by a workspace administrator and are not part of the marketing surface.
Native history and optional context are different things
The distinction matters, because a product should never imply it holds history it does not have, or context it has not been granted.
1 · Native history
What the product recorded itself, available because you hold that product.
- Calls, campaigns, conversations and records produced in that product
- Full detail, retained while you hold the product
- Available regardless of whether you hold the other products
2 · Optional context
What another product adds when it is held and the viewer is permitted to see it.
- Labelled with the product that produced it
- Shown only when your workspace holds that product
- Withheld, with a plain explanation, when you do not
3 · The boundary
Where one product stops and the other begins is visible, not implied.
- A product badge on any panel from another product
- No record copied into a product that does not hold it
- A missing product shown as a dependency, not as empty data
Permissions and access
Connection questions
Connect the source, then add the products
Connect your accounting system and see your business first. Add a product when a workflow has earned it, under the same permission model.