General guidelines for record naming conventions

When you create new records, consider the following naming conventions:

• Choose names that reflect the purpose of the record.
• Keep names short but long enough to make the purpose of the record evident.
• For readability, start all names with a capital letter. Start additional words within names with capital letters. Capitalize any acronyms in names.
• Do not include underscores or other special characters, except as noted in particular scenarios.
• When you create records, the system automatically generates the record identifier by using text that you enter in the Label field. The system removes spaces and special characters that you include in the label and capitalizes the first letter of each word in the identifier.
• Names of records that are part of specific functional groups can start with the function name, or an abbreviation of the name, followed by an underscore, and then a record name. Do not use this naming convention for rules from which other rules inherit. For example, names of data pages start with D_ characters.
• Start the names of active rules, such as activities and flows, with a verb indicating the main action of the rule. Include a noun or noun phrase that indicates the element on which the rule operates.
• For passive or object records, such as parameters, properties, work parties, libraries, and roles, choose nouns or noun phrases that describe the main purpose of the rule. For example, ProjectGoalDate, ClaimID, or DefenseAttorney.
• Use hyphens in class names to control pattern inheritance. For example, when you name a class SLAforHA-ReviewClaims, you indicate that the parent of this class is the SLAforHA class.

Limitations on name lengths for rule types and objects

• A ruleset name that uses pyRuleSet property can have the maximum length of 128 characters.
• An operator ID value that uses the pyUserName property can have the maximum length of 128 characters.
• The internal key of an object that uses the pzInskey property, can have the maximum length of 255 characters for most tables. Longer file names cause compilation issues in Windows environments.
• A class name that uses the pxObjClass property, for a class you create can have the maximum length of 56 characters. The system generates parallel History- classes for most classes that you create, and consequently reaches the 64 character limit for class names.
• The visible key that uses the pxInsName property can have the maximum length of 128 characters.
• The short description for a record that uses the pyLabel property can have the maximum length of 64 characters. As a best practice, enter a maximum of 30 characters.
• A property name can have the maximum length of 64 characters.
• The system name, that is a key of the Data-Admin-System data instance, can have the maximum length of 32 characters.
• A node name can have the maximum length of 32 characters.
• An assignment name can have the maximum length of 32 characters.

Naming conventions for flow actions and assignments

Use noun and verb combinations for flow actions and assignments, for example SubmitPurchaseOrder and ReviewJobApplication. Ensure that names are meaningful to users as the text appears in numerous locations in the end user interface, for example worklists and menus in user portals.

Additionally, flow actions can reference other records. When you associate a flow action with an activity or validation record, prefix the flow action name with one of the following prefixes:

• For pre-activities, use Pre, for example, PreAcceptCorrespondence.
• For post-activities, use Post, for example, PostAcceptCorrespondence.
• For validation records, user Val, for example ValApproveCorrespondence.

When you name sections and privileges that are related to flow actions, apply the same guidelines as for flow actions.

Naming conventions for access groups

Choose a name that is unique system-wide, both in the current system and in other Pega Platform systems that may later host your application. Ensure that the access group name contains one colon character. Use an ApplicationName:RoleName format, for example, BakingOperations:Customer or LoanRequests:Administrator. As a result, you ensure that the name is unique across multiple applications. Begin the name with a letter and use only alphanumeric, ampersand, dash characters, and a single colon.

For more information about access groups, see Learning about access groups.

Naming conventions for data objects

Data objects are classes that contain the information such as properties and data pages that are necessary for a case to accomplish actions or achieve business outcome. For example, in a banking application, a Customer data object might include properties such as Name, Phone number, and Address, so that you can conveniently identify and contact customers. Use nouns that clearly communicate what a data object includes when you name data objects.

For more information, see Creating a data object.

Naming conventions for database objects

Database objects include tables, views, indexes, and so on created in the Pega Platform database or other databases that a Pega Platform application uses. In general, name database tables in accordance with the location of the respective work or data class in the Customer Enterprise Class Structure (ECS). Names of standard Pega Platform database tables begin with pr_, pc_, or pi_. Numerous use cases require creating your own tables to supplement the standard tables. As a best practice, use the application/ruleset name as a suffix, for example MyApp_, and to try to resemble the existing name. For example, name the work table MyApp_work.

For database objects, use the same name as the class or class group and use one of the following ending suffixes:

• TB for a table
• IN for an index
• SY for synonyms
• SQ for a sequence

Map work tables on the implementation layer so that multiple lines of business (LOB) can use the same framework application to map to different database tables. Name work tables by using the following format: LOB name_work_workpool name. Ensure that abbreviations of line of business name and workpool name match the abbreviations in the Customer ECS, except for DB2 table names.

The following example include sample work tables names:

• For ABCD line of business and Order Intake workpool, name the table abcd_work_orderintake.
• For Claims line of business and Contracts workpool, name the table claims_work_contracts.

Name work history tables by using the following format: LOB name_work_history_workpool name. Ensure that abbreviations of line of business name and work pool name match the abbreviations in the Customer ECS. For example, for ABCD line of business and Order Intake workpool, name the table abcd_work_history_orderintake.

Name division-wide data tables by using the following format: LOB name_data_domain name. For example, for a Claims line of business and Provider domain, name the data table claims_data_provider.

Name enterprise-wide data tables in the following format: ent_data_domain name. For example, for a Networks domain, name the data table ent_data_networks.

Ensure that abbreviations of line of business name and domain name match the abbreviations in the Customer ECS.

Name constraints on a database tables that contain work or data by using the table name and suffix _PK, which stands for primary key. For example, for a claims_work_contracts database table, name the constraint claims_work_contracts_pk.

Naming conventions for files

For records that derive from Rule-File- class, select a name that uses only lowercase characters to avoid confusion between systems which have case-sensitive file names systems which do not have case-sensitive file names. Begin the names of files for related functions with a common prefix character so they appear grouped together in listings.

Naming conventions for flows

Name flows by using a combination of a verb and a noun that clearly describes a purpose of the flow, for example Submit an order.

For more information, see Defining the case life cycle.

Naming conventions for functions

Follow Java naming standards, which include initial lower case, then camel case, for the Function Name key part of a function record, because functions define Java functions.

Naming conventions for HTML streams

For an HTML stream, choose a noun or a noun phrase that indicates the main data that the stream displays. If possible, relate the name to the name of the activity or action that displays the stream. For example, WorkSummary. Use camel case in HTML stream names.

Naming conventions for router activities

For more information, see Assigning tasks to users.

Naming conventions for service packages

A service package supports the development of services that your application offers. A service package name becomes the first key part of a set of service records that are packaged and deployed together. Create a service package data instance for each service. As a naming convention, use the following format:

<application name><service type><optional deployment type><optional unique part>

The following list includes sample service package names:

• LOANSSOAP
• LOANSEJBV2
• LOANSEMAIL
• LOANHTTPA, LOANHTTPB, LOANHTTPC

For more information, see About Service Package data instances.

Naming conventions for work queues and work groups

Use the name that clearly identifies the purpose of the work queue followed by the suffix WQ, for example, AnalystsWQ or UnderwritingWB.

Work groups usually identify a group of workers that have similar process responsibilities. Use a name that clearly identifies the purpose of the group followed by the suffix Group, for example, HelpDeskGroup or BenefitsGroup.

For more information, see Creating a work queue.

Naming conventions for specific records

For more information about naming conventions for records, refer to the specific documentation for each record:

• Constraints rules -
• Declare Expression rules - Completing the New or Save As form
• Creating a privilege
• Creating a When rule
• Creating rulesets
• Naming conventions for classes
• Naming conventions for properties
• Creating an activity
• Case status values
• Configuring data transform
• Creating operator IDs
• Creating a case type
• Adding a stage to a case life cycle
• Adding a process to a stage
• Adding a step to a process

Naming conventions for other objects

For indexes, views, triggers, and stored procedures, use the same naming criteria as for activities. Start with a verb that indicates what the database object does, followed by a noun or a noun phrase that indicates what the view does. End the name with the appropriate suffix. Maximum length for such names is 15 characters. The following list includes the suffixes that you can use when you name the objects:

• vw for views
• tr for triggers
• in for indexes
• rp for reports
• sp for stored procedures
• te for trigger events, with further distinctions:
  • te_ai for After Insert events
  • te_bi for Before Insert events
  • te_au for After Update events
  • te_bu for Before Update events
  • te_bd for Before Delete events