Projects can use the same SharePoint platform and still require different identifiers, suitability codes, and revision procedures. Keep those agreed rules explicit so that a client requirement can be implemented and reviewed without being hidden in application logic.
Establish the applicable information standard
Record the standards, national provisions, client requirements, and appointment arrangements that apply. ISO 19650 does not prescribe a universal SharePoint configuration. The project needs a concrete information standard and agreed methods for producing and exchanging information.
For each configurable rule, record its source, owner, allowed variation, and acceptance test. Distinguish a mandatory requirement from an internal preference before implementing either.
Separate identifier structure from allowed values
The 2021 UK National Annex approach uses Project, Originator, Functional Breakdown, Spatial Breakdown, Form, Discipline, and Number. This is a national convention, not a universal international filename syntax.
The UK BIM Framework Guidance Part 2, Edition 6 explains changes including the former Role field becoming Discipline and revised field-length guidance.
In the implementation, define both the field sequence and its governed values. Assign ownership of code lists, prevent duplicate identifiers, and decide how retired values remain available for historical information. Generating a formatted filename is only one part of that work.
Keep suitability separate from CDE state
CDE state describes the information’s place in the managed workflow. Suitability metadata communicates its permitted use under the applicable convention. Store and validate these concepts separately.
In the 2021 UK approach, S4 relates to review and authorization, and S5 to review and acceptance. The guidance records the removal of S6 and S7. Assigning S4 or S5 does not perform the corresponding activity or establish its outcome.
Configure the permitted transitions, responsible roles, and required evidence. A choice list can present valid codes; the release process must establish whether the conditions for using a code have been met.
Distinguish formal revisions from file versions
SharePoint version history records changes and supports viewing or restoring previous versions. A formal project revision represents information under the agreed revision convention. Several technical file versions may belong to one formal revision.
Define when a revision changes, who may assign it, and which file version was issued under that revision. Keep a retrievable relationship between the identifier, formal revision, reviewed content, and release record.
Version and test the configuration
Consider a project that introduces a new discipline code after the first delivery. Add the code through the designated owner, record its effective date, and test new submissions. Decide whether existing information needs adjustment; do not rewrite historical issue records merely to make them match the latest list.
Apply the same discipline to changes in approval stages or required metadata. Test the effect on pending reviews, integrations, and historical retrieval before deployment.
Configuration is useful when the platform already supports the required rule type. An unfamiliar validation condition or exchange process may still need development. Include that boundary in the assessment of Flinker’s CDE application or a custom SharePoint solution.
For maintaining and deploying these rules with workflow automation, read managing CDE rules alongside Power Automate.