Freshworks Neo is the platform layer under Freshdesk, Freshsales, Freshservice, and the rest. Treat it as plumbing and you’ll miss capabilities. Treat it as a full PaaS and you’ll be disappointed.
What Neo actually provides
- Unified Identity (single login across products)
- Marketplace runtime (serverless app hosting)
- Event bus (cross-product workflow triggers)
- Crayons design system (React component library)
- Common Object Model (shared contacts and accounts)
What Neo does not provide
- General-purpose database (use external storage for app state)
- Custom authentication providers (Identity is opinionated)
- Long-running background jobs (apps are event-driven, time-boxed)
- Native vector search (you wire your own)
Where the event bus changes designs
If Freshdesk receives a ticket from a known Freshsales contact, a Neo event can trigger a Freshsales activity log entry. You do not need a Marketplace app to bridge these two products if you use the cross-product workflow rules.
Source: Freshdesk ticket created
Filter: contact.email matches Freshsales contact
Action: Append timeline entry to Freshsales contact
Common Object Model gotchas
Updating a contact in Freshdesk via API does not always sync to Freshsales unless the products are in the same Org. Cross-org tenants do not share the COM. Confirm your tenant topology before promising single-source-of-truth.
Building on Neo: app patterns
Marketplace apps run as serverless functions in the Neo runtime, with a 20-second execution cap and no persistent storage. State must live elsewhere: KV via the platform’s Data Storage API, or your own backend.
$db.set("user_pref:" + userId, { theme: "dark" }, { ttl: 86400 });
What to do this week
Map your tenant org structure, list which products share the COM, identify one cross-product workflow you currently solve with Zapier, and replace it with a native Neo event rule.