Nuxeo Online Services

Naming Conventions

Updated: May 17, 2018 Page Information Edit on GitHub

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.

General rules

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.

Content Model

  • 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

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 ]:

  • CM-01-UI-SendToValidation
  • CM-02-UI-SendToValidated
  • CM-03-UI-SendBackToDraft

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

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

Event Handlers

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...

3 months ago manonlumeau Update Designer intro page with University Links
2 years ago Karin Touchie 25
3 years ago Solen Guitter 24 | Fix format and TOC
4 years ago Vincent Dutat 23
5 years ago Solen Guitter 22 | Updated operation link to use Explorer
6 years ago Solen Guitter 20 | Added TOC
6 years ago Solen Guitter 21 | Migrated to Confluence 4.0
6 years ago Frédéric Vadon 19
6 years ago Frédéric Vadon 18 | typo
6 years ago Frédéric Vadon 17
6 years ago Frédéric Vadon 16
6 years ago Frédéric Vadon 15
6 years ago Frédéric Vadon 14
6 years ago Frédéric Vadon 13
6 years ago Frédéric Vadon 12
6 years ago Frédéric Vadon 11
6 years ago Frédéric Vadon 10
6 years ago Frédéric Vadon 9
6 years ago Frédéric Vadon 8
6 years ago Alain Escaffre 7
6 years ago Frédéric Vadon 6
6 years ago Frédéric Vadon 5
6 years ago Frédéric Vadon 4
6 years ago Frédéric Vadon 2
6 years ago Frédéric Vadon 3
6 years ago Frédéric Vadon 1
History: Created by Frédéric Vadon

We'd love to hear your thoughts!

All fields required