Limnn is a suite built on one graph rather than a bundle of separate apps. Understanding how modules share objects lets you decide what to enable, in what order, and how to extend the model without creating duplicates.
How linking works
- A contact or account created in Sales is the same object a Support ticket or invoice links to.
- An employee in People is linked to the user account used to sign in, so org chart and permissions align.
- Tasks and projects in Grid can reference deals, tickets or employees without copying data.
- Reports and Cortex query the graph directly, so a metric reflects all modules at once.
Planning a rollout
- 1List the two or three workflows that hurt most today and map each to a module.
- 2Enable those modules at /settings/module-access and leave others off to keep navigation focused.
- 3Import core records first (people, accounts, contacts) at /settings/import so links exist before transactions.
- 4Add custom fields at /settings/fields and pick lists at /settings/pick-lists to match your vocabulary.
- 5Configure pipelines at /settings/pipelines and approvals at /settings/approvals.
- 6Pilot with one team, review /reports dashboards, then widen the rollout.
Extending the model
Custom fields add attributes to existing objects, and custom engines at /settings/custom-engines let you define new object types that participate in permissions, reporting and search like built-in ones. Use custom fields first; reach for a custom engine only when the thing you track is genuinely a new kind of record.
Disabling a module hides it but keeps its data and links. Re-enabling restores everything, so it is safe to trial modules.