NAM Default Business Rules old

A naming rule defines the format used to generate names. It consists of a set of naming parts, with each part corresponding to an attribute or property of the object type to which the rule is applied.

A special naming part of type ‘sequence’ can be added to the collection. Sequences generate an auto-incrementing value each time a new name of that type is created.

Naming rules are stored in a tenancy-wide library located in the CONNECT folder. This shared library is accessible across all scopes within the NAM tenancy.Any changes made to a naming rule, or its type mappings are automatically reflected in all scopes where the naming rule is used. They can also be grouped into Rule Sets to simplify management. 

Note:
Use caution when modifying naming rules or type mappings, particularly when a rule is shared across multiple scopes. Careful consideration before making changes helps prevent unintended impacts across different scopes.

Business Rules

Here are a few business rules that have been established: 

The Fixed and Digits properties of the naming part have been removed. Previously, these properties ensured that the number of digits in that part matched the exact value specified in the Digits field. This can be achieved using the min length, max length, padding, and pad up to properties.

The Required field on a naming part has been removed. Previously, it indicated whether a value for that part was optional or mandatory. . This behavior is now controlled by the Min Length property, which determines whether a part must be provided.

The Part of Uniqueness field is no longer in the name part configuration. To replicate the functionality, use the Sequence Criteria field within the Primary Sequence name part.

Sequence reservation works on primary numeric sequence only. 

The text-type counter only accepts uppercase characters. 

Min and max length from naming rule are strict. Any allocation requests that violate these constraints will be rejected. 

Scopes 

A scope represents an application, project, asset, or any other defined context. Name Contexts are created within each scope, to establish boundaries for groups of names. These groupings are often based on the attribute or property that the client application uses to store or reference the generated name.

A Name Context ensures that the fully qualified name remains unique within that context. Each Name Context refers to a Rule Set as well as a collection of individual naming rules, allowing flexibility in how names are generated and validated.

A Name Context can include multiple naming rules for the same class. This allows conditional execution, enabling the system to select the appropriate naming rule based on the defined conditions.

Note:
In this release, multiple naming rules for the same class are not supported from Engineering. The only supported scenario is the Preserve Name option used during compare and update operations.

Deleting a scope removes all name contexts and all allocated names and sequences associated with it.
There is no check for whether a scope has assigned names before it is deleted. Due to this, deleting a scope can result in unintended data loss, so it is important to proceed with caution.
A scope can theoretically support around 10 million name allocations based on calculated estimates. However, this figure has not been validated through real world testing, and there may be discrepancies in the actual number of allocations a scope can handle. 
It is recommended to distribute name allocations across multiple scopes rather than approaching the upper limits of a single scope. This strategy improves performance and maintainability while reducing the likelihood of unexpected issues.

Integration with Engineering