Scattered sources
The same name or label is re-entered across Confluence, Jira, Assets, LeanIX, and app config.
Telops · Group IT · Content Management · 2025
IT content lives in many systems, and every catalog is handled differently. We bring translations, knowledge, products, services, SLAs, and apps under one model: authored in friendly tools, versioned in Git, released through CI/CD, and served translated through APIs.
This deck is the method — how we manage content. Its heart is the catalogs: the versioned bodies of content this model governs. For where this sits in the wider system see Platform; for the app that authors it see Product Pilot.
The content pattern
One repeatable way to version, approve, translate, and serve catalog content.
01 · Problem space
Translations, knowledge, products, services, SLAs, and app metadata live in separate systems with separate rules — no shared way to review, translate, version, or release them.
The same name or label is re-entered across Confluence, Jira, Assets, LeanIX, and app config.
Approval, translation, and permissions differ per catalog; reviewing changes in Jira is painful.
No staging, no versioning, no changelog. Translations drift and rollbacks are guesswork.
02 · The big picture
Surfaces share content through a single API instead of each one wiring directly into JSM, Assets, and Confluence. Underneath, content lives in purpose-built stores, and people plus automation keep it curated and released. Colour indicates the system or domain.
Surfaces that share content
Where content lives
Who changes it
03 · The content catalogs
What each catalog holds. They all sit on a shared translation layer of curated terminology reused everywhere.
Markdown articles: title, body, tags, attachments, and locale variants.
Name, description, variants, options, pricing, and images — each anchored to a stable SKU identity that carries through ordering, fulfilment, and billing.
Service name, description, linked request types, and fulfilment content.
Service-level targets, response and resolution times, scope, and policy text.
Group name, members, routing rules, and ownership metadata.
App name, rich description, screenshots, and icon, layered on LeanIX records.
Product names, service names, descriptions, departments, and form labels in EN, DE, ES, and more. Strings are namespaced (app · path · topic) and reused across the Back Office, Axpo Hub, emails, and notifications.
04 · How each type is handled
Each type keeps its natural authoring tool but plugs into the same versioning, approval, translation, and release flow.
The shared terminology catalog. Namespaced strings feed the Back Office, Axpo Hub, emails, and notifications from one place.
Authored in a dedicated IT Confluence space, mirrored as markdown in Git via the API. CI generates changelogs and enables rollbacks; approvals link to Jira; approved content is copied to public spaces.
JSM content stays tuned for service staff. Public form fields, titles, and errors come from the translation layer, and can be written into Assets where objects need localised fields.
Authored in the Back Office, stored in Git, approved through JSM. Released versions write back to JSM Assets (CMDB).
LeanIX records enriched with descriptions, screenshots, and icons in Git, published through the Back Office on the same flow.
05 · Who it affects
They use the portal and read articles exactly as they do today.
Chosen fields in requests and Assets stay in sync via API.
Edit in the Back Office; translations flow to apps, emails, and comms.
06 · Anatomy of an update
One change, end to end. Colour marks the system that owns each step.
07 · Interfaces
Content reaches people through three surfaces. These are the same three views the Platform deck defines in full — here they are framed by what content each one consumes or controls.
Reads products, services, and articles as formatted, translated JSON.
Authoring, review, and approval for IT staff — and the trigger for releases.
Holds requests and CMDB objects; selected content syncs via API.
08 · Git and CI/CD
Content rides the same release machinery as everything else. The pipeline mechanics and environments live in the Platform deck; here is what that buys content specifically.
Readable diffs, auto-generated changelogs, and rollback to any known-good release.
Proper review and comparison instead of editing live content blindly.
GitHub Actions write back to Confluence, JSM, and Assets consistently.
Preview translations and product options, validated with automated tests.
09 · API delivery
Accept-Language header and receive fully formatted, translated JSON.Consumers never handle translations. They send the desired language and receive the right content, fully formatted.
10 · What this unlocks
Images and media served from Azure storage, managed through CI/CD.
IT staff change, review, and approve in the Back Office.
Rate-article and suggest-improvement signals from other apps or JSM.
Usage tracked in the IT Portal and Confluence to act on what matters.
Agents check links, formatting, and naming across catalogs.
Rovo support flows update KB articles, synced back through the same process.