---
title: "Interface Register Template (IDK-13)"
date: 2026-09-21
description: "Ready-to-use template IDK-13: Interface Register for IFS Cloud implementation projects, aligned with the IFS implementation methodology."
author: "Dariusz Mysliwiec"
categories:
  - name: "Implementation docs kit"
    url: "https://www.ifs-erp.com/implementation-docs-kit.md"
---

# Interface Register Template (IDK-13)

Template IDK-13, version 1.0. Phase: Confirm Prototype (must exist before build starts), maintained through Go Live and into support.

 ## How to use this template

 
- List every interface: the ones that exist around the legacy system today and the ones the new solution will need. Include file drops, spreadsheets uploaded by hand on a schedule, and reports that another system reads. If data crosses a system boundary, it is an interface.
- Start the inventory in Confirm Prototype. The register must be complete before build starts, because a forgotten interface is usually found during cutover.
- The register is split into three tables that share the same ID: identification and flow (section 4), mechanism and security (section 5), operation and status (section 6). In a spreadsheet they can be one wide table.
- Every new or changed interface also gets a row in the CRIM log (template [IDK-10](https://www.ifs-erp.com/en/marketplace/implementation-docs-kit/10-crim-log)) and a functional specification (template [IDK-11](https://www.ifs-erp.com/en/marketplace/implementation-docs-kit/11-functional-specification-integration-modification)).
- Review the register at each gate and at every release update. Hand it to support at go-live.
- Delete the rows marked `Example:` once your own rows exist.

 | Field | Value |
| --- | --- |
| Template ID | IDK-13 |
| Phase | Confirm Prototype (must exist before build starts), maintained through Go Live and into support |
| Owner | Customer technical analyst for integrations, supported by the technical solution manager |
| Approver | Customer project manager, steering group for new write interfaces and retained legacy interfaces |
| Qualification gate | Solution Confirmed |
| Version | 1.0 |

 ## Contents

 
- [Document control](#document-control)
- [1. Rules for this register](#1-rules-for-this-register)
- [2. Value lists](#2-value-lists)
- [3. Decisions on legacy interfaces](#3-decisions-on-legacy-interfaces)
- [4. Register part A: identification and flow](#4-register-part-a-identification-and-flow)
- [5. Register part B: mechanism and security](#5-register-part-b-mechanism-and-security)
- [6. Register part C: operation and status](#6-register-part-c-operation-and-status)
- [7. Checks per interface before SAT](#7-checks-per-interface-before-sat)
- [8. Cutover and decommissioning](#8-cutover-and-decommissioning)
- [9. Review at each release update](#9-review-at-each-release-update)
- [10. Handover to support](#10-handover-to-support)
- [11. Approval](#11-approval)

 ## Document control

 | Field | Value |
| --- | --- |
| Project | [Project name] |
| Register owner | [Name, role] |
| Technical solution manager | [Name] |
| Security owner on the customer side | [Name] |
| Storage location | [Link] |
| Review rhythm | [For example at each gate, and before each release update] |

 | Version | Date | Author | Change |
| --- | --- | --- | --- |
| 0.1 | [YYYY-MM-DD] | [Name] | Inventory of legacy interfaces |
| [x.y] | [YYYY-MM-DD] | [Name] | [Change] |

 ## 1. Rules for this register

 
1. Every interface has one named business owner and one named technical owner on the customer side.
2. Every interface runs under its own integration account with its own permission set. No shared accounts and no personal accounts.
3. Read-only is the default. Write access to IFS Cloud is granted only with steering group authorisation and a functional specification.
4. Retaining a legacy interface is a decision, not a default. It needs the same authorisation as a new one.
5. Credentials have a named custodian. The register records who holds them, never the secret itself.
6. Every interface states how failures are detected and who acts on them. "Someone will notice" is not monitoring.
7. Updates to IFS Cloud go through standard projections or IFS Connect and their business logic. No direct database access.

 ## 2. Value lists

 | Column | Allowed values |
| --- | --- |
| Origin | Legacy retained / Legacy replaced by standard / Legacy retired / New |
| Direction | Inbound to IFS Cloud / Outbound from IFS Cloud / Both |
| Mechanism | REST/OData projection / IFS Connect (message routing, transformers, connectors) / File transfer / Event action / Manual upload / Other |
| Access | Read-only / Write |
| Status | Identified / Decision pending / Approved / Specified / In build / In test / Accepted / Live / Retired |

 ## 3. Decisions on legacy interfaces

 Walk through the legacy landscape with IT and the functional teams. Ask for each system: what goes in, what comes out, who would call if it stopped.

 | Legacy interface | Purpose today | Decision | Reasoning | Decided by, date | Register ID if retained or replaced |
| --- | --- | --- | --- | --- | --- |
| Example: Nightly stock file to the web shop | Web shop shows availability | Replaced by a read-only projection call | File is a day old, customers order stock that is gone | [Steering group], [YYYY-MM-DD] | INT-002 |
| Example: Purchase price export to a spreadsheet tool | Monthly price analysis by purchasing | Retired | Covered by a standard overview page and a lobby | [Customer PM], [YYYY-MM-DD] | None |
| [Interface] | [Purpose] | [Decision] | [Reasoning] | [Name, date] | [ID] |

 ## 4. Register part A: identification and flow

 | ID | Name | Origin | Source system | Target system | Direction | Data objects | Business owner | Technical owner |
| --- | --- | --- | --- | --- | --- | --- | --- | --- |
| Example: INT-001 | Supply chain exception monitoring | New | IFS Cloud | External monitoring service running in the customer network | Outbound from IFS Cloud | Purchase order lines, supplier confirmations, receipts. Object keys, dates, quantities and statuses. No writes. | Purchasing manager | [IT integration lead] |
| Example: INT-002 | Availability to web shop | Legacy replaced | IFS Cloud | Web shop | Outbound from IFS Cloud | Inventory part availability per site | Sales manager | [IT integration lead] |
| [ID] | [Name] | [Origin] | [Source] | [Target] | [Direction] | [Objects] | [Name] | [Name] |

 ## 5. Register part B: mechanism and security

 | ID | Mechanism | Projections, messages or files used | Access | Integration account | Permission set | Authentication | Credentials custodian | Network path |
| --- | --- | --- | --- | --- | --- | --- | --- | --- |
| Example: INT-001 | REST/OData projection | [Purchase order and receipt projections, entity sets listed in the specification] | Read-only | [Dedicated account, for example `SVC_PO_MONITOR_RO`] | [Dedicated permission set granting read on the listed projections only, no actions, no write] | [OAuth client credentials through the IFS identity provider] | [IT security officer]. Secret stored in [vault]. Rotated every `[agree in project]`. | Inside the customer network to the IFS Cloud endpoint over HTTPS. No inbound connection from outside. |
| Example: INT-002 | REST/OData projection | [Inventory availability projection] | Read-only | [Dedicated account] | [Dedicated permission set] | [OAuth client credentials] | [Web shop platform owner] | [Path] |
| [ID] | [Mechanism] | [Objects] | [Read-only / Write] | [Account] | [Permission set] | [Method] | [Role, storage, rotation] | [Path] |

 ## 6. Register part C: operation and status

 | ID | Frequency or trigger | Volume | Error handling | Monitoring and who acts | CRIM log ID | Specification link | Status | Test evidence |
| --- | --- | --- | --- | --- | --- | --- | --- | --- |
| Example: INT-001 | Scheduled poll every `[agree in project]` | `[agree in project]` | Failed reads are retried and logged with object keys only. The service cannot change data, so no business recovery is needed in IFS Cloud. | Service health check reviewed by [IT integration lead]. Failed authentication raises an alert to the credentials custodian. | [ID] | [Link] | In test | Read access verified with the integration account. Write attempt verified as refused. [Tester], [YYYY-MM-DD] |
| Example: INT-002 | On request from the web shop | `[agree in project]` | Web shop shows "availability on request" when the call fails | Web shop platform monitoring, alert to [owner] | [ID] | [Link] | Specified |   |
| [ID] | [Frequency] | [Volume] | [Handling] | [Monitoring, role] | [ID] | [Link] | [Status] | [Evidence] |

 ## 7. Checks per interface before SAT

 | Check | Done |
| --- | --- |
| Row complete in parts A, B and C | [ ] |
| Functional specification approved, commercial approval in place where needed | [ ] |
| Integration account created with its own permission set. Tested that it cannot do more than listed. | [ ] |
| For read-only interfaces: a write attempt has been tested and was refused | [ ] |
| Error handling tested with at least one forced failure | [ ] |
| Monitoring in place and the named person has received a test alert | [ ] |
| Volume test done where section 6 shows significant volume | [ ] |
| Interface included in an end-to-end SAT script | [ ] |
| Entry added to the cutover plan: switch-on time, legacy switch-off time, verification step | [ ] |

 ## 8. Cutover and decommissioning

 | ID | Action at cutover | When (reference to cutover plan line) | Owner | Verification | Rollback action |
| --- | --- | --- | --- | --- | --- |
| Example: INT-002 | Stop the nightly legacy file. Enable the projection call in the web shop. | [Line reference] | [IT integration lead] | Web shop shows availability for a test part that matches IFS Cloud | Re-enable the legacy file job |
| [ID] | [Action] | [Reference] | [Name] | [Check] | [Action] |

 Legacy interface accounts and scheduled jobs to remove after go-live: [list with owner and date].

 ## 9. Review at each release update

 | Check | Owner | Done |
| --- | --- | --- |
| Release notes read against the projections and messages in part B | [Role] | [ ] |
| Each live interface smoke-tested in the update test environment with its real account | [Role] | [ ] |
| Permission sets still grant what is listed and nothing more | [Role] | [ ] |
| Credentials rotation is up to date | [Role] | [ ] |
| Interfaces with status "Live" but no traffic: owner asked whether they can be retired | [Role] | [ ] |
| Register version updated and shared with support | [Role] | [ ] |

 ## 10. Handover to support

 The list of third-party integrations is part of the handover document. For each live interface, support receives the register row, the latest functional specification, the test specification, the name of the credentials custodian and the monitoring contact.

 | Item | Done |
| --- | --- |
| Register reflects production, verified by the technical owner | [ ] |
| Specifications at the linked locations are the latest versions and in English | [ ] |
| Support has been walked through each interface in the handover meeting | [ ] |

 ## 11. Approval

 Approval at the Solution Confirmed gate states that the inventory of legacy and new interfaces is complete to the best knowledge of those signing, and that the decisions in section 3 are authorised.

 | Role | Name | Decision | Date | Signature |
| --- | --- | --- | --- | --- |
| Customer IT or integration lead | [Name] | [Approved / Approved with comments / Rejected] | [YYYY-MM-DD] |   |
| Customer security owner | [Name] |   |   |   |
| Customer project manager | [Name] |   |   |   |
| Technical solution manager (reviewed) | [Name] |   |   |   |
| Steering group chair (write interfaces and retained legacy interfaces) | [Name] |   |   |   |

 Comments and conditions: [text]

 Independent template aligned with the IFS implementation methodology. Not an official IFS document. IFS is a registered trademark of IFS AB.

 Independent template aligned with the IFS implementation methodology. Not an official IFS document. IFS is a registered trademark of IFS AB.