Technical Documentation Template

Azure AD SSO Integration — SAP S/4HANA (production)


Technology Stack
Azure AD SAML 2.0 SAP NetWeaver
Environment
Production
Document Owner
MKMarie Kowalski
Last Verified
14/01/2026 — Next review: 14/07/2026

📖 Overview

This document describes the single sign-on (SSO) integration between Azure Active Directory and SAP S/4HANA via SAML 2.0. The integration enables 2,400 users across 3 business units to authenticate against the corporate identity provider, eliminating separate SAP credentials and enforcing MFA policies centrally.

🏗️ Architecture

  • Identity Provider: Azure AD tenant (elium-prod.onmicrosoft.com) — SAML 2.0 metadata endpoint
  • Service Provider: SAP NetWeaver AS ABAP 7.54 — SAML 2.0 service provider configured via transaction SAML2
  • Certificate: SHA-256 signing certificate issued by DigiCert, valid until 31/03/2027
  • Claim mapping: Azure AD UPN → SAP user alias (BNAME); department attribute → SAP activity group

⚙️ Configuration

ParameterValue
Entity IDhttps://sap-prod.elium-infra.eu/sap/saml2/sp
ACS URLhttps://sap-prod.elium-infra.eu/sap/saml2/sp/acs
NameID Formaturn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress
Sign AssertionsYes (SHA-256)

⚠️ Known issues

Session timeout mismatch: Azure AD session lifetime (60 min) exceeds SAP ICM timeout (30 min), causing re-authentication prompts mid-session. Workaround: increase ICM parameter icm/HTTP/session_timeout to 3600 in transaction RZ10. Permanent fix pending SAP Note 3412055 (scheduled SP08).

Content continues in Elium...

Capture technical knowledge — system architecture, configuration steps, API references, environment setup — in a consistent, searchable format. This template ensures documentation stays current and accessible, so teams resolve issues faster and onboard new engineers without relying on tribal knowledge.

Try now in Elium

What is technical documentation?

Technical documentation is a structured reference that describes how a system, application, or infrastructure component works — covering its architecture, configuration, interfaces, and operational procedures in a format that engineers can follow without prior context.

Good technical documentation eliminates single points of knowledge failure. When system details exist only in the heads of the engineers who built them, every departure or role change creates risk. A structured template enforces consistency: each document follows the same format and can be found through the same search. Any qualified engineer can pick up any system — without tracking down the original author.

Who should use this template?

This template is for teams that build, operate, or support technical systems:

  • System Administrators — document server configurations, network topologies, and maintenance procedures so knowledge survives team changes
  • DevOps and Platform Engineers — capture deployment pipelines and infrastructure-as-code patterns in a shared format
  • IT Support Managers — ensure L2/L3 support staff have accurate system references when troubleshooting escalated issues
  • Technical Writers — maintain consistent structure and terminology across all system documentation in the knowledge base

What’s included in this template?

The template has two parts: structured metadata fields and the documentation body.

Metadata fields classify each document:

  • Document title and system identifier
  • System or application name
  • Technology stack (e.g. Linux, AWS, SAP, .NET)
  • Environment (production, staging, development)
  • Document owner — the engineer accountable for keeping it current
  • Last verified date and next review date

Documentation body covers the system in depth:

  • Overview — what the system does, its role in the wider architecture, and key dependencies
  • Architecture — components, data flows, and integration points with diagrams where useful
  • Configuration — settings, parameters, and environment variables with expected values
  • Setup and installation — step-by-step instructions for deploying or rebuilding the system from scratch
  • Operations — routine maintenance tasks, monitoring thresholds, and backup procedures
  • Known issues — documented quirks, limitations, and workarounds with their root causes

How to create and customise this template in Elium

  1. Open the Template Builder — Go to your profile menu and select the Template Builder tab, or click “+ Create” and choose “Create a new template”.
  2. Set the scope — Choose an icon, enable the template, and decide whether it applies platform-wide or to specific spaces (e.g. your Infrastructure or Engineering space).
  3. Add structured fields — Click “Field” to add metadata: text fields for document title and system identifier, tag fields for technology stack and environment, a user field for document owner, and date fields for last verified and next review. Mark system name and document owner as mandatory.
  4. Build the documentation structure — Use the “+” button to add content blocks: text blocks for overview and architecture, a code block for configuration parameters, a numbered list block for setup steps, text blocks for operations and known issues. Add placeholder prompts (e.g. “What components does this system depend on?”).
  5. Preview and save — Review the template layout, then save. Engineers can now create documentation using a consistent format, and you can apply it to existing content in bulk.

Decision Tree ready: This template also works as an Elium Decision Tree — instead of reading through a static document, guide your team through step-by-step questions that lead directly to the right answer. Learn more about Decision Trees.

How AI helps you create and use this template

Capture faster. Paste architecture notes or configuration files into Elium’s AI. It identifies system components, dependencies, and setup steps — then generates a structured first draft that the engineer reviews rather than writing from scratch.

Retrieve smarter. An engineer asks Elium’s AI: “How do I configure the VPN gateway for the Frankfurt data centre?” The AI returns the exact configuration parameters and setup steps from the relevant document — no scrolling through folders.

Why teams use Elium for technical documentation

Technical documentation decays fast. Systems change, configurations evolve, and documents written months ago describe a state that no longer exists. The challenge is not writing documentation — it is keeping it accurate and findable. Elium combines structured templates with AI-powered search, so engineers find the right document and trust that it reflects current reality.

VINCI Energies — 97,000 employees across 61 countries — faced this at scale. Their IT department of 1,000 engineers had procedures scattered across Word, SharePoint, OneNote, and Teams. By centralising technical knowledge in Elium, they built a single reference point: 4,000+ articles across 110+ spaces, used by 500+ engineers daily. As their team lead noted, the success of a knowledge base depends on a tool that is dynamic, user-friendly, and easy to use.

Frequently asked questions

Technical documentation is a structured reference describing how a system works — its architecture, configuration, interfaces, and operational procedures. Without it, system knowledge stays trapped with individual engineers. When those people leave, change roles, or are unavailable, teams lose the ability to maintain, troubleshoot, or rebuild critical systems quickly.
A complete template includes metadata (system name, technology stack, environment, document owner, review date) and body sections covering overview, architecture, configuration, setup instructions, operations, and known issues. The best templates also include decision points for environment-specific variations and links to related systems.
Structured technical documentation reduces mean time to resolution because support staff find accurate system references immediately. It shortens onboarding because new engineers learn systems from documented architecture rather than shadowing colleagues. It improves change management because every modification starts from a documented baseline rather than assumptions.
Start with the audience: who will read this and what do they need to do? Describe the system from the top down — purpose, architecture, then detail. Use consistent terminology and include actual configuration values, not placeholders. Assign a document owner, set a review cycle, and treat documentation updates as part of every change request.
Technical documentation describes how a system works under normal conditions — its architecture, configuration, and operational procedures. A troubleshooting guide addresses what to do when something goes wrong — symptoms, diagnostic steps, and resolution paths. Technical documentation is the reference; the troubleshooting guide is the response plan. Both should link to each other.

Related reading: Read more on our blog