---
title: "CRIM Log Template (IDK-10)"
date: 2026-09-21
description: "Ready-to-use template IDK-10: CRIM Log 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"
---

# CRIM Log Template (IDK-10)

Template IDK-10, version 1.0. Phase: Confirm Prototype (needs identified), Establish Solution (specified, built, tested).

 ## How to use this template

 
- CRIM stands for Configurations, Reports, Integrations and Modifications. This log is the single register of everything in the solution that is not plain standard functionality.
- Open the log at the first workshop. During Confirm Prototype you only record needs. Specification and build start in Establish Solution, after the decision column is filled.
- Every row must answer the question in the column "Standard alternative considered". A row without that answer is not ready for a decision.
- The register is split into two tables that share the same ID: section 5 covers need and decision, section 6 covers delivery and handover. In a spreadsheet they can be one wide table.
- Review the log at every weekly PM-to-PM meeting and present the summary in section 8 to each steering group.
- Delete the rows marked `Example:` once your own rows exist.

 | Field | Value |
| --- | --- |
| Template ID | IDK-10 |
| Phase | Confirm Prototype (needs identified), Establish Solution (specified, built, tested) |
| Owner | Supplier project manager, with the technical solution manager |
| Approver | Customer project manager for configurations and reports, steering group for integrations and modifications |
| Qualification gate | Solution Confirmed (needs identified), Solution Established (objects delivered) |
| Version | 1.0 |

 ## Contents

 
- [Document control](#document-control)
- [1. Purpose and the "standard first" rule](#1-purpose-and-the-standard-first-rule)
- [2. Type definitions](#2-type-definitions)
- [3. Tailoring levels and update impact](#3-tailoring-levels-and-update-impact)
- [4. Status values](#4-status-values)
- [5. Register part A: need and decision](#5-register-part-a-need-and-decision)
- [6. Register part B: delivery and handover](#6-register-part-b-delivery-and-handover)
- [7. Decision authority and change control](#7-decision-authority-and-change-control)
- [8. Summary for the steering group](#8-summary-for-the-steering-group)
- [9. Update-impact review](#9-update-impact-review)
- [10. Handover checklist](#10-handover-checklist)
- [11. Approval](#11-approval)

 ## Document control

 | Field | Value |
| --- | --- |
| Project | [Project name] |
| Log owner | [Name, role] |
| Technical solution manager | [Name] |
| Customer project manager | [Name] |
| Storage location | [Link] |
| Review rhythm | Weekly PM-to-PM meeting, summary to every steering group |

 | Version | Date | Author | Change |
| --- | --- | --- | --- |
| 0.1 | [YYYY-MM-DD] | [Name] | Log opened |
| [x.y] | [YYYY-MM-DD] | [Name] | [Change] |

 ## 1. Purpose and the "standard first" rule

 The aim of the project is to meet each process need with standard IFS Cloud functionality, and to keep the count of modifications, integrations and configurations as low as the business can accept. Every CRIM object has a cost at build time and again at every update. The log makes that cost visible before anyone commits to it.

 The rule, applied to every row:

 
1. Describe the business need, not the wished-for solution.
2. Show the standard functionality to the requester in the system. Record what was shown.
3. Record why standard is not sufficient, in the requester's words and with the consequence for the business.
4. Only then propose a CRIM object, at the lowest tailoring level that meets the need.
5. If the justification is "this is how the legacy system works", the row is rejected or sent back.

 ## 2. Type definitions

 | Type | Covers | Specification needed | Approval before build |
| --- | --- | --- | --- |
| C: Configuration | Custom fields, custom events, page configurations, lobbies, workflows (Business Process Automation), custom pages and similar objects created in the web client | Configuration and report specification (template [IDK-12](https://www.ifs-erp.com/en/marketplace/implementation-docs-kit/12-configuration-and-report-specification)) | Customer project manager |
| R: Report | Quick reports, operational report layouts, analysis models and other outputs beyond standard | Configuration and report specification (template [IDK-12](https://www.ifs-erp.com/en/marketplace/implementation-docs-kit/12-configuration-and-report-specification)) | Customer project manager |
| I: Integration | Any data exchange with another system, in either direction, including file transfers. Also listed in the interface register (template [IDK-13](https://www.ifs-erp.com/en/marketplace/implementation-docs-kit/13-interface-register)) | Functional specification (template [IDK-11](https://www.ifs-erp.com/en/marketplace/implementation-docs-kit/11-functional-specification-integration-modification)) | Customer approval, commercial agreement, steering group authorisation |
| M: Modification | Any change to delivered application logic or pages that goes beyond configuration | Functional specification (template [IDK-11](https://www.ifs-erp.com/en/marketplace/implementation-docs-kit/11-functional-specification-integration-modification)) | Customer approval, commercial agreement, steering group authorisation |

 ## 3. Tailoring levels and update impact

 Use these levels in the "Tailoring level" column. Adjust the wording to the terms agreed with your implementation partner.

 On the three-level scale used on ifs-erp.com: Standard corresponds to Level 1 Core, Configuration to Level 2 Configured, Modification to Level 3 Customized. An interface extension installs nothing in the tenant, so the core stays at Level 1, but the consumer carries the re-verification duty shown below.

 | Level | Meaning | Typical update impact |
| --- | --- | --- |
| Standard | Solved with standard functionality and basic data. Logged only to record the decision. | None beyond normal regression testing |
| Configuration | Created in the web client, stored as configuration, moved between environments as configuration packages | Low. Re-verify after each release update, especially page configurations and objects that rely on specific fields. |
| Interface extension (published interfaces) | External logic or integration that uses projections (REST/OData) or IFS Connect without changing delivered code | Medium. Re-verify the projections and entities consumed at each release update. |
| Modification | Changed or added application code, built and delivered through the Build Place | High. Must be uplifted, rebuilt and retested for each release update. Limits how often the customer can update. |

 ## 4. Status values

 | Status | Meaning |
| --- | --- |
| Identified | Need logged during a workshop. No decision yet. |
| Standard adopted | Standard alternative accepted. Row closed at Standard. |
| Rejected | Need not accepted. Reason recorded. |
| Approved for specification | Decision made to proceed. Specification may start. |
| Specified | Specification approved by the right approver (see section 2). |
| In build | Build started. For I and M, commercial approval is in place. |
| In test | Delivered to the test environment. Test evidence being collected. |
| Accepted | Customer has accepted the object based on test evidence. |
| Handed over | Latest functional and test specification delivered to support. |

 ## 5. Register part A: need and decision

 | ID | Type | Solution area and process | Business need | Standard alternative considered (what was shown, why it is not sufficient) | Decision | Decided by, date | Tailoring level | Update-impact note |
| --- | --- | --- | --- | --- | --- | --- | --- | --- |
| Example: CRIM-001 | C | Procurement, purchase to receipt | Buyers need one view of order lines the supplier has not confirmed | Standard purchase order lines overview with a saved search was shown. It works, but buyers want counts and ageing on their start page. | Approved as a lobby | [Customer PM], [YYYY-MM-DD] | Configuration | Lobby data source reads purchase order line data. Re-verify elements after each release update. |
| Example: CRIM-002 | M | Procurement, requisition approval | Requester asked for a bespoke approval screen like the legacy one | Standard authorisation rules plus an approver lobby were shown. They cover the delegation of authority policy fully. | Rejected, standard adopted | [Steering group], [YYYY-MM-DD] | Standard | None |
| Example: CRIM-003 | I | Inventory, stock visibility | Web shop must show available quantity per part | Standard projection for inventory part availability was reviewed. No standard connector to the web shop exists. | Approved for specification, read-only | [Steering group], [YYYY-MM-DD] | Interface extension | Re-verify projection and entity set names at each release update. See interface register [ID]. |
| [ID] | [C/R/I/M] | [Area, process] | [Need] | [Alternative and justification] | [Decision] | [Name, date] | [Standard / Configuration / Interface extension / Modification] | [Note] |

 ## 6. Register part B: delivery and handover

 | ID | Specification link and version | Estimate and commercial approval (I and M) | Builder | Status | Test evidence (script, result, tester, date) | Accepted by, date | Handover status |
| --- | --- | --- | --- | --- | --- | --- | --- |
| Example: CRIM-001 | [Link], v1.0 | Not applicable | [Customer technical analyst] | Accepted | SAT script [ID], passed, [tester], [YYYY-MM-DD] | [Process owner], [YYYY-MM-DD] | Specification and test case delivered to support on [YYYY-MM-DD] |
| Example: CRIM-003 | [Link], v1.2 | Estimate `[agree in project]`, change request [ID] approved [YYYY-MM-DD] | [Developer] | In test | Integration test [ID], open defect [ID] |   | Not started |
| [ID] | [Link] | [Reference] | [Name] | [Status] | [Evidence] | [Name, date] | [Status] |

 ## 7. Decision authority and change control

 | Situation | Who prepares | Who reviews | Who decides |
| --- | --- | --- | --- |
| New configuration or report need | Functional team: need, alternatives with pros and cons, proposal | Solution architect, technical solution manager | Customer project manager |
| New integration or modification need | Functional team: need, alternatives with pros and cons, proposal | Solution architects, then both project managers for cost | Sponsor agrees to table it, steering group authorises or rejects |
| Change to an approved specification | Author of the specification | Both project managers | Same authority as the original approval, through a written change request |
| Need raised after Solution Confirmed | As above | As above | Always through change control against the scope baseline |

 Write the disagreement down. In many cases, setting out the alternatives on paper resolves the question before it reaches the steering group.

 ## 8. Summary for the steering group

 | Type | Identified | Standard adopted or rejected | Approved | Specified | In build or test | Accepted | Handed over |
| --- | --- | --- | --- | --- | --- | --- | --- |
| Configurations | [count] | [count] | [count] | [count] | [count] | [count] | [count] |
| Reports | [count] | [count] | [count] | [count] | [count] | [count] | [count] |
| Integrations | [count] | [count] | [count] | [count] | [count] | [count] | [count] |
| Modifications | [count] | [count] | [count] | [count] | [count] | [count] | [count] |

 Trend since the last steering group: [text]. Rows that need a steering group decision today: [IDs, each with a one-page decision paper].

 ## 9. Update-impact review

 Run this review when planning every release update, and in lighter form for service updates. The more Interface extension and Modification rows the log holds, the longer this review takes and the less often the customer can update. Say that plainly when a new row is proposed.

 | Check | Owner | Done |
| --- | --- | --- |
| All rows at Configuration, Interface extension and Modification listed with their update-impact note | [Role] | [ ] |
| Release notes read against the objects, projections and pages each row depends on | [Role] | [ ] |
| Regression test cases from the test evidence column scheduled in the update test plan | [Role] | [ ] |
| Modification rows: uplift effort estimated and agreed before the update date is committed | [Role] | [ ] |
| Rows no longer needed because standard now covers the need: proposed for retirement | [Role] | [ ] |

 ## 10. Handover checklist

 Support cannot verify a fix without a test specification. Check every accepted row before handover.

 | Check | Done |
| --- | --- |
| Latest approved specification stored at the link in part B | [ ] |
| Test specification with expected results stored with it | [ ] |
| Documents are in English | [ ] |
| Integrations also appear in the interface register with credentials custodian named | [ ] |
| Owner after go-live named on the customer side | [ ] |
| Row status set to "Handed over" only after the handover meeting | [ ] |

 ## 11. Approval

 Approval of this log at a gate confirms that the list of CRIM objects is complete for the phase and that the decisions recorded are those of the named authority. It is not approval of individual specifications.

 | Gate | Role | Name | Decision | Date | Signature |
| --- | --- | --- | --- | --- | --- |
| Solution Confirmed | Customer project manager | [Name] | [Approved / Approved with comments / Rejected] | [YYYY-MM-DD] |   |
| Solution Confirmed | Steering group chair | [Name] |   |   |   |
| Solution Established | Customer project manager | [Name] |   |   |   |
| Solution Established | Steering group chair | [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.