Naming or renaming objects

Query reports

If you modify an out of the box query report, for example a manager query, do not rename it. Instead, give it a custom object label and a revision to indicate upgraded objects that were modified to merge existing configurations. For more information on custom object labels, see Preparing to upgrade.

Workflows

Do not use the old practice of copying and modifying out of the box workflows. Instead, configure workflows directly without renaming them. Then use object labels to track changes. For more information, see Object naming and revisioning.

Business objects

If you create a business object for some new functions, name it with a "cst" (custom) prefix and then add the name of the base object. For example, cstBuilding.

To avoid confusion with out of the box objects, do not prefix new objects with "tri".

Make the name descriptive of what the function of the object is or what data is being stored.

Name business objects as follows: cst[MixedCaseNoSpacesName].

Associations

Create meaningful association names. To avoid any clashes with existing associations, make sure the association string that you are creating does not exist already.

Publish names

Publish names are composed of one or more fields with combined values that define a record as unique.

A Publish Name is a unique identifier for a record, formed by combining one or more fields (like Name + ID). Publish Names help ensure data integrity during imports, updates, and system referencing activities. Publish Names act as a human-readable primary key that helps distinguish records and prevent duplicates when you are loading data by using tools like Data Integrator.

Field names

Prefix new field names with “cst”, for example, a field name that is added to the triPeople business object might be named “cstSecondaryLocationTX” (note the camel case). The suffix “TX” (text”) indicates the type of the field.

Field lengths

You can increase and decrease field lengths. However, you cannot label fields, so track any changes in field lengths in a tool like Jira.

You cannot have field lengths shorter than the shortest existing field length.

To change the field length, revise and then publish the business object.

Formulas for number fields

If you change the formula for a number field, the Business Object receives a revision of that change.

Changes to formulas and field lengths have an “in progress” label at the Business Object level not the attribute level.

Changes to field attributes do not have any field labels, but when changes to field attributes happen, then the business object has a label change.

Changes to fields and formulas are labeled at the Business Object level only. The platform does not identify individual field changes. Changed formulas have “in progress” label.

Check the label to see what is changed in the Business Object. The label does not show the nature of the change. However, you can compare objects with in “progress labels” to see what is changed between the two versions. Use the Data Modeller tool to do this comparison.

You can also export the comparison into an Excel sheet to see what changes were made between versions. For example Business Object field changes, state changes, and family changes.

Generating field labels

Whenever you change a field, whether it is the length or the formula, any of these changes in the business object, generate a new “in progress” object label.

Every field has a label attribute. So, if you change that label that is reflected as a change in the business object.

States and state transitions

Prefix added and modified states and state transitions with “cst” and then add a descriptor. For example, if an object does not have a completed state and you add a completed state, the name for that completed state must be “cstCompleted”.

Rename modified states and state transitions from “tri” to “cst” and then include a descriptor.

State transitions best practices

• If you change the label on a state transition, updating the name flags it as something to be retrofitted after upgrade.
• If you change the state to call a different workflow, then change the name of the state.
• When you change the name of a state, check the ‘whereabouts of used’ in the field triRecordStateSY. Sometimes workflow switch tasks might reference the original name.
• Another best practice is to add new workflow logic or call custom workflows from a workflow that is called by a state sub action.
• Transition actions and transition sub actions have names and labels.

Forms

If you create a form that points to an out of the box business object. For example, creating a form for the employee object.

Name such forms as follows: cst[MixedCaseNoSpacesDescriptiveName].

Lists

Lists are not labeled or managed. Instead, provide detailed external documentation in a repository like Jira describing the changes made, by whom, and why.

Modules

Name modules as follows: cst[MixedCaseNoSpacesDescriptiveName].

Workflow steps and tasks

Configured workflows have a custom (cst) object label, they do not have the IBM label. When modifying a workflow, it is tagged as “in progress” and is given a custom object label.

You can also itemize the changes in the description of the workflow by including the changes that are made to a specific logic step.

Conditions or switches

If you change logic in an out of the box switch, note the change in the workflow description of the start task.

An example of a change is adding logic that states if the record is retired and you try to activate it, it can activate it only if certain conditions are true.

Portals and portal sections

If the portal or section is a new object, give it a "cst" prefix. If the portal or section is an existing object, do not change the name. Instead, use the object label to identify what is modified.

Navigation collections and items

If the collection or item is a new object, create it with a "cst" prefix name. If it is an existing object, do not change the name. Instead, use the object label to identify what is modified.