Processes should be named using a conjunction of an identifier and an actual descriptive name to allow for easier searching while still being informative enough.

The identifier in the name should be a running number with some abbreviation to elaborate on the context of the Process. For instance, a Process name could be in the form of:

001 would be the running number in the context of Enterprise Resource Planning which would be indicated by the ERP abbreviation. The actual descriptive name would be Product price information to ERP, which would be separated from the identifier with a dash. This naming convention allows for an easy search process and easy management of Processes.

As the context of integrations can be a cross section of an enterprise, and if the number of integration Processes is very high, the abbreviation could also be a combination of the resources in the context of the specific Process, for instance 001ERPHR where the integration Process would cover ERP and HR.

When implementing APIs and the Processes for every method of a specific API, developers should rely on Frends to give those Processes their names as they are generated and linked from the API List View.

In the end, the most efficient Frends Process naming convention is both commonly agreed upon and consistent.

The naming convention of Subprocesses should be implemented with the same descriptive format as Processes. It is suggested that Subprocesses should have an identifier and a descriptive name with a dash as a separator.

The next article is Best practices on Naming APIs