Skip to main content
Use this guide when you add or update files in release-notes/.

​
Follow the format by version line

  • SuperOffice 12 and newer (the current major version) use the Mintlify Update component in the major-version index.mdx page, such as release-notes/12/index.mdx, and are the only version line that gets real content edits.
  • SuperOffice 11 and earlier, and Pocket CRM, should receive formatting updates only. Do not make content edits there. This applies regardless of which structural format a version happens to use: SuperOffice 11 now uses the same Update+Badge component as 12 (see release-notes/11/index.mdx), but it’s a historical version, so it stays formatting-only just like 10.x and earlier.
  • Mobile CRM uses the Update component too, split across release-notes/mobile/v11.mdx and release-notes/mobile/v10.mdx. See Update mobile release notes below.
  • Integrations uses the Update component - one per integration.

​
Write SuperOffice 12 and newer release notes

For each minor version:
  • Add one <Update> block per minor version, latest at the top.
  • Add one H3 heading per feature item inside that update.
When stepping to a new major version:
  1. Create a new folder in release-notes/, for example release-notes/13/.
  2. Add index.mdx for the new major version.
  3. Add the new page to config/nav-releases.json.
  4. Update the release-notes pointer in docs.json’s markdown.instructions to the new major version.
  5. Continue using the same Update-based structure.
Use the release-notes-major-version template.

​
Badge map for feature headings

Do not use a Core CRM badge or tag in SuperOffice 12 and newer, because it is easily confused with the CRM Suite Core tier. Features that don’t belong to a module badge below get a plain heading.

​
Use stable anchors

Each minor update needs a persistent anchor:
Put the feature heading text first, the module <Badge> after it, so the heading text gets visual focus instead of being pushed right. Each feature H3 can also define a Mintlify anchor override so you can deep-link to that specific feature. The anchor must always be the last token on the heading line, regardless of what else is on it. Otherwise Mintlify fails to parse the page, and the Deployment check can still report success while it silently keeps serving the page’s previous content:

​
Update mobile release notes

For Mobile CRM:
  • Add one <Update> block to release-notes/mobile/v11.mdx (or v10.mdx for a v10.x backport), latest at the top. No new file and no new nav entry is needed for a routine update: both files are already wired into config/nav-releases.json.
  • Add one H3 heading per feature inside that update, matching the plain-heading style already used there (no <Badge>: Mobile CRM is one product line, not a multi-module system, so it doesn’t need a module badge per feature the way SuperOffice 12 and newer do).
  • Use the file’s existing tags={[...]} convention for filtering (for example ["Diary", "Follow-ups"]), carried over from what used to be the file’s category/topic frontmatter.
  • Add screenshots with the -app-screen suffix in the image alt text, and place the image files in /media/loc/en/mobile/.
  • Give the update a stable anchor the same way as SuperOffice 12 and newer:
    When a version has more than one feature, add an explicit anchor to each feature H3 too, so it can be deep-linked individually: ### Feature title {#11.2.0-1}.
  • Add a bullet for the new update to the changelog list in release-notes/mobile/index.mdx, linking to the update’s anchor (for example ./v11#11.2.0).
  • When mobile itself needs a fresh split (not simply because a new desktop major version ships), create the next file (for example v12.mdx), add it to config/nav-releases.json, and add a wildcard redirect in config/redirects.json for the version line it replaces.

​
Update EOL announcements

EOL content is maintained independently of release-note updates. To update EOL:
  1. Edit release-notes/eol/index.md.
  2. Add a row to the current or upcoming table.
  3. Optionally link the first-column product or feature to a new dedicated page in release-notes/eol/ if you need a detailed message.

​
Leave generated API and database notes alone

API and database release notes are generated content, including MAJOR/api/ such as release-notes/12/api/. Do not hand-edit generated release-note files. Generated files use their original generated filename (for example changes-webapi-12.2.2072.0.md) directly under MAJOR/api/ - no per-version subfolder.

​
Related content