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. Continue using the same Update-based structure.
Use the release-notes-major-version template.

​
Badge map for feature headings

​
Use stable anchors

Each minor update needs a persistent anchor:
Each feature H3 can also define a Mintlify anchor override so you can deep-link to that specific feature:

​
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