Resources
Academy, product notes, webinars, developer surface, marketplace, and support — operator-grade, not a content farm.
Library
Start with Academy if you are learning. Developers if you are extending. Customers if you need proof.
Free tracks for operators who design queues and close.
Product and operator notes worth a Friday read.
Sessions that end in the running app.
Summits, meetups, roadshows.
API, Builder, Functions, sandbox.
Extensions on CEDX identity.
Academy first, then humans on Desk.
Release-shaped updates.
Full-depth illustrative rollouts.
For builders
API, Builder and Functions sit next to the apps your customers already run. Sandbox before prod.
Operating model
Academy tracks and quick reads before pilot kickoff.
Enablement kits after approval; public Academy for basics.
API, Builder, Functions, sandbox - identity first.
Start here
| If you are... | Start | Then |
|---|---|---|
| Evaluating CEDX | Customer scenarios | Live product pages |
| Running a pilot | Academy | Support model |
| Selling or implementing | Partner program | Partner resources |
| Extending the estate | Developers | Marketplace |
Why this library exists
Most software vendors publish for SEO calendars. We publish when a pilot team would actually use the page on a Thursday afternoon: estate map, academy track, partner kit, or API surface.
The resource center is the map of that library. Academy teaches the work. Blog holds sparse essays. Webinars and events put the live product on stage. Developers and Marketplace extend the estate without a second login. Support and News cover the operating reality after go-live.
If you are evaluating CEDX, start with customer scenarios and the product catalog. If you are already in a pilot, start with Academy and Support. If you sell or implement, start with the partner program and partner resources after approval.
Editorial bar
We do not ship thin listicles that rename features as insights. We do not maintain a parallel mockup universe for marketing. Product pages embed the running app; essays that point at a product should open that app.
Partner-only depth stays behind the portal on purpose. Public pages should still be useful without a login: checklists, sequences, and honest FAQs.
Role paths
Evaluators start with customer scenarios and the product catalog, then open three live apps on one user to follow one customer record across seams. That test reveals whether you are buying an estate or another glue project.
Pilot teams start with Academy tracks, quick reads, and the Support model, then write three metrics and a retire list before config sprints. Pair modules with the live product pages for the first motion you will land.
Partners start with the program home, tiers, and portal resources after approval, using public Academy for basics and labs for deeper practice. Events seat practitioners who deliver rather than badge collectors.
Builders start at Developers, API, Builder, Functions, sandbox, and Marketplace listing rules with identity non-negotiable. Sandbox before production is not optional guidance; it is how review expects you to work.
Library streams
News is release-shaped programme and product notes, not essays and not curriculum. Blog is sparse writing that changes how you evaluate or run the estate on a Friday.
Academy is work design with checklists; webinars and events put the live product on stage with Q and A. Docs and in-app help are reference surfaces next to the running apps.
Partner-only kits stay behind the portal so co-sell assets are not scraped into competitors' decks. Public pages remain useful without login: sequences, comparison frames, honest FAQs, and live product links.
When you are lost, use the recommended-path table on this hub, then book a thirty-minute estate map with Friday's queue in hand. Feature wishlists without operator context produce demos that do not convert into clean pilots.
Product truth
Product pages embed the real app and captures come from that build so marketing cannot invent a prettier falsehood. Essays and Academy modules that point at a product should open that product in the same session.
Webinars cancel if the app will not open; partners demo what they implement; training does not depend on two-version-old screenshots. When drift appears, we fix product or capture pipeline rather than shipping a new PNG of fiction.
This standard is harder operationally and cheaper commercially than bait-and-switch discovered mid-implementation. Prospects get one answer to does it look like this, which is the only answer that survives procurement screenshares.
Security and IT should evaluate identity and entitlements on the same plane operators use, not on a slide appendix disconnected from the demo tenant. Ask for the live path early; static-only evaluation is a risk signal.
Support and next steps
Work-design questions start in Academy; account and product defects go to Support with impact, estate context, and already-tried notes. Delivery configuration issues start with the implementing partner when one owns the SOW.
Severity is business impact, not inbox volume; breach risk and close windows escalate differently than cosmetic UI. Named ownership on high severity continues until clear with status in-thread.
Open the catalog when you need product truth; open scenarios when you need industry-shaped narrative; open partner find when you need delivery muscle. Open developers when you need to extend without forking a shadow CRM.
Contact for estate map booking when the library still leaves a gap; bring products in scope, retire list draft, and three candidate metrics. Leave with owners, not only a recording of a demo.
Content types and when to use them
Use customer scenarios when you need industry-shaped full depth with products, timeline, and roles. Use Academy when you need checklists and work design before config.
Use product pages when you need live software truth for a specific surface. Use blog essays when you need an argument that changes evaluation posture, not a feature list.
Use News for programme and release-shaped updates; use webinars and events for live Q and A and labs. Use Developers and Marketplace when extension is in scope; use Support when the account or product is blocked.
Use partner program pages when you sell or implement; use partner resources after approval for kits that track live builds. Do not confuse /partners/ PRM product pages with /partner-program/ programme pages.
If you open more than five tabs without writing three metrics and a retire list, stop and write the map. Library thrash is not evaluation progress.
For procurement and security readers
Send the security product narrative and partner security pack path, the identity discussion from Developers and estate map practice, and live product embeds rather than only PDFs. Committees that only receive decks approve fiction.
Call out illustrative scenario language honestly; do not overclaim audited outcomes the site does not claim. Trust compounds when marketing and security tell the same story.
Ask for an estate map session with security and operators together so access and queue design do not fork into incompatible requirements. Late security constraints are the most expensive kind.
Data processing and legal paper live on their own URLs; do not expect Academy modules to replace counsel review. Partners should use non-binding templates only as starting points.
Feature matrices are fine as supplements; the decisive test remains one user, three apps, one customer record. Document that test result in the evaluation packet.
For operators mid-pilot
Open the Academy module that matches this week's pain, run the checklist with the people who own the queue, and capture decisions in the pilot doc the same day. Deferred decisions become configuration debt.
Open the matching live product and verify the decision is possible without a custom side system. If it is not, escalate architecture early rather than inventing a spreadsheet bridge.
Open Support only after Academy and in-app help fail for work design, or immediately when severity impact is real. Include reproduction and estate context so routing is correct.
Open partner contacts if a partner owns delivery; do not bypass them for config issues they implemented. Bypassing creates conflicting changes and finger-pointing.
End the week by checking the three pilot metrics in the live system without exports if possible. If you needed exports, write down why and whether that reason dies in the next wave.
For partner marketers and AEs
Send the product page URL for the motion, one customer scenario in the buyer's industry, and the partner path page that matches your firm. Avoid attaching outdated screenshot PDFs when the live page exists.
Use battlecards from the portal after approval; they are versioned against live builds. Public site copy is safe to quote with attribution; partner-only kits are not for public redistribution.
For multi-product pursuits, send the estate one-login essay and ask for a three-app live walkthrough in the next meeting. That frames evaluation on seams, where you win against glue stacks.
Register the opportunity before heavy co-sell asks; clean registration is how SE time is allocated fairly. Last-minute registration on a verbal-only deal creates conflict and bad blood.
After wins, submit outcome notes through partner success so scenarios and enablement can improve. Silence after go-live wastes learning the whole channel needs.
FAQ
Core tracks and quick reads are free. Partner labs unlock after program approval.
Start at /developers/ and the API product page.
Academy first, then /support/ and contact for account issues.
Release-shaped notes under /news/; longer essays under /blog/.
Yes for basics. Deeper labs and kits unlock after program approval.
Tell us your role - operator, partner, or builder - and we will point you.
