Skip to content

CRIM file responsibility map

Use this map before editing. File ownership and generation settings matter as much as the extension. This is a 26R1 reference draft; confirm the exact structure in your target project.

File or object Responsibility What to edit
Entity Configuration Runtime custom attributes Configure and publish through supported tooling
Page Designer configuration Runtime page placement and properties Edit in the intended configuration context
ACP Configuration transport package Export, validate, and import through lifecycle tooling
.entity Persistent entity attributes and relationships The appropriate customization model; inspected models may use XML, while documentation also illustrates text syntax
.projection Service entities, attributes, operations, and types Cust declarations for supported extensions; inspect Core mappings and included fragments
.client Page, group, list, and field declarations The owning client customization, with the correct projection and element names
.fragment Shared model declarations Trace the include and supported extension point; do not duplicate shared declarations blindly
.plsql Entity business logic Supported customization hooks when generated attribute behavior is insufficient
.plsvc Projection operation implementation Generated method stubs in the appropriate source layer; preserve the actual signature
.report Operational report model and data contract Customer-owned report definition in Report Modeler
.rdf Report data assembly and database artifacts Regenerate when model-generated; edit only when deliberately maintained as manual source
.xsd and sample XML Report schema and preview data Regenerate from the owned report contract
.rdl Report Designer layout Edit using compatible layout tooling; other layout types have their own formats
.pltst / .plsvt Server or service test sources Follow the test framework and examples present in your project
Entity attribute -> projection property -> client field
| | |
persistence rules service contract page placement

A UI control does not create storage. Storage does not automatically make a field available on every projection. An exposed property does not automatically place it on every page.

Follow the complete modification field walkthrough for example declarations and a verification sequence.

Use the customization wizard to create layer-aware source files. Names such as OrderHeader-Cust.entity are illustrative; inspect the generated file names and declarations for your project.

Do not patch generated database packages to make a source change appear to work. Regeneration can overwrite the patch. For reports, explicitly establish whether the RDF is generated or manually maintained before choosing where to change data assembly.

A configuration package and a code delivery are separate mechanisms. If a requirement needs both, document their dependencies and test the full delivery sequence.