This page proposes naming conventions for Studio customization items in order to facilitate usage, maintenance and support. Although not mandatory, we strongly encourage you to follow these conventions, especially if you are a beginner in Studio. For each rule, an example is provided.
In general, there are items that will be easily seen by end users (document types for instance) and under the hood features (automation chains for instance). For very exposed items, words should be separated by an underscore and begin with a capital letter (Contract_Library) and for others we will prefer compacity: capital letter for every words but no underscore between them (SendToValidation for instance).
As Studio projects can be mixed together or involve many functionalities (ex: contract management, holiday requests...), it is important that items coming from one project or another can be identified easily. The solution is to prefix every item. For example every item that is about contract_management will start with CM- and HR- will apply for holiday request: CM-SendToValidation. Prefixing does not apply to document types, and lifecycles (Content Model section in Studio). This is particularly mandatory when you do a plugin that will become an Application Template that can be imported into other projects.
- Document types - Document types are probably the main items and should be created first. Naming should start with a capital letter, and if it needs several words, these one should be separated with an underscore: Contract_Library.
- Schemas - Explicit name (the same as the document type if linked to one) with underscore separating words but all lower case: contract_library. You should use a prefix that is either the name or a shorter prefix like dc for dublin_core.
- Lifecycle - Upper case for each first letter, underscore to separate them. Most of the time a lifecycle is only for one document type, in that case, the lifecycle should name after the doc type with Lifecycle at the end: Contract_Lifecycle.
- Lifecycle State - all lower case, words separated by underscore. Transitional states and stable states should be distinguished, for instance a document that requires to be corrected and then validated will have the states: correction > validation > validated
Search and Listings
Named like under the hood items: explicit name, no word separation but capital first letter and the project prefix. For example, a content view that shows all contracts in validation state would be: CM-ContractsInValidation.
Automation chain names should contain a verb to describe what they do.
Some automation chains have a UI context, which enables to use UI operations like Add Info Message. These chains should be prefixed with UI. A example of a chain that send a contract to validation from a user action could be: CM-UI-SendToValidation.
Other chains that do not have UI context and are mainly called by event handler or other chains should be prefixed with Sub. Example: CM-Sub-UpdateAcl.
Items in automation are clearly under the hood items so it would be explicitly named: no word separation but capital first letter and the project prefix. We also added a few rules to standardized the description.
When automation chains are steps of a workflow, a good idea is to prefix them with a number so that they are displayed in the same order they will be triggered. Example with a workflow on the lifecycle [Draft <--> Validation --> Validated ]:
Note that CM-02-UI-SendToValidated and CM-02-UI-SendBackToDraft have the same number as they can be triggered from the same state (Validation).
User actions should be named after the automation chain they trigger, adding UA- (User Action) after the project prefix (possibly adding the user action category at the end as there can be several user action launching the automation chains).
Example of a user action to send a contract to validation: CM-UA-SendToValidation
Same rule as user actions but with EH instead of UA: CM-EH-UpdateAclOnContractCreation
Every other item should follow the rules given at the top of this page.
Vocabularies should have a name shorter than 13 characters, otherwise, it may be too long for some databases
Most of the time, groups of users come from the AD or LDAP, but when created in Studio, it should reflect the role, in full lower case, with a "s" at the end: members, redactors, purchasers...