All runbooks
Under construction · working draft requires a release manifest

Technical runbook

Configuring integrations

Rules for identities, EIS, eSSL, document services, and other connectors.

Audience
Integration analyst, implementer, identity manager, target system supplier
Outcome
Each binding has an owner, a contract, a security model, and a solvable error path.

01

The contract of each bond

  • source and destination, owner of both parties and record keeping system
  • API version and supported compatibility
  • network direction, DNS, TLS and allowed certificate authorities
  • authentication of the technical service and transfer of the identity of the real user
  • timeout, retry, backoff, idempotence and duplication protection
  • correlation ID, audit, monitoring and escalation contact
  • data classification, minimization, retention and log masking

02

Identities and permissions

  • SSO via OpenID Connect or SAML 2.0 configures trust with IdP/Keycloak according to the specific environment.
  • A supported design can use Microsoft Entra ID, Shibboleth, CAS (Jasig / Apereo), LDAP, NIA, or CAAIS; the exact protocol version, claims, and account lifecycle are part of the integration profile.
  • A group from an identity is not automatically a process role; the mapping must be controlled and tested.
  • MFA or passkeys are enforced in a supported identity architecture.
  • Technical accounts have minimal rights, rotated secrets, and separate auditing.
  • Removing a user and changing a role are authenticated in the same way as logging in.

03

Economic system, accounting and financial resources

  • The case, tasks, approvals and reasons for return are recorded by OOD/SIFYBOX; the accounting document, accounting number and official posting status are recorded by the economic system.
  • The internal accountant can have a step directly in the process. The external accountant can take over the approved documents in his system. The connector can create a document only to the extent confirmed by the specific interface.
  • SIFYBOX only stores the status that the economic system actually returns: sent, technically received, document created or posted. These statuses are not combined.
  • The available budget is authoritative in the finance system when it provides that information; FS stores the decisive control snapshot. Local allocations or reservations are authoritative in FS only when the integration contract explicitly says so.
  • Suppliers and accounting dimensions come from a designated master system; SIFYBOX holds a controlled copy and a source identifier.
  • Resubmission uses the same idempotency key. Timeout with an unclear result leads to reconciliation, not to automatic creation of another document.
  • The error will create a task for a specific solver and will not remain only in the technical log.

04

eSSL and NSeSSS

  • The process application does not replace a certified eSSL.
  • It passes the component, metadata, and unique identifiers via a confirmed interface according to NSeSSS.
  • It saves the returned registration data and status so that the user does not overwrite anything.
  • Ownership of the file, disposal rules, and authoritative document is determined prior to implementation.
  • Specific supported eSSLs and versions are included in the release integration matrix.