Skip to main content

Naming Conventions

Following consistent naming conventions for workflow components ensures your code is maintainable, understandable, and follows EmpowerID best practices. This reference guide provides the standard naming patterns for forms, data sources, lookups, and form data objects.

Why Naming Conventions Matter​

Consistent naming conventions provide several benefits:

  • Clarity - Component names clearly communicate their purpose and type
  • Maintainability - Other developers can quickly understand your workflow structure
  • Searchability - Standardized names make it easier to find specific components
  • Best practices - Following conventions aligns with EmpowerID standards

Naming Convention Patterns​

Forms​

Forms should follow the pattern that begins with company initials, followed by the verb, target resource type, and concludes with "Form."

Pattern: {CompanyInitial}{Verb}{TargetResourceType}Form

Example: CIEditPersonAddressForm

Breakdown:

  • CI - Company initials
  • Edit - The verb (action being performed)
  • PersonAddress - The target resource type
  • Form - Indicates this is a form component

Common verbs:

  • Create
  • Edit
  • Update
  • Delete
  • View
  • Select

Additional examples:

  • CICreateAccountForm - Form for creating accounts
  • CIUpdateGroupMembershipForm - Form for updating group membership
  • CIDeletePersonForm - Form for deleting a person
  • CIViewBusinessRoleForm - Form for viewing business role details

Data Sources​

Data sources should begin with a descriptive name that represents the data being provided, followed by "DataSource."

Pattern: {ObjectName}Datasource

Example: CountryDatasource

Explanation: The name should be self-explanatory. A data source named CountryDatasource clearly indicates it provides a list of countries.

Additional examples:

  • StateDatasource - Provides a list of states
  • DepartmentDatasource - Provides a list of departments
  • LocationDatasource - Provides a list of locations
  • BusinessRoleDatasource - Provides a list of business roles
  • TimeZoneDatasource - Provides a list of time zones

Best practices:

  • Use singular form for the object name (Country, not Countries)
  • Make the name descriptive enough to understand the data without additional context
  • Avoid abbreviations unless they are widely recognized

Lookups​

Lookups should begin with a meaningful object name and append "Lookup" at the end. You can use "Single" or "Multiple" to indicate the selection type, and abbreviations to keep names concise.

Patterns:

  • {ObjectName}Lookup
  • {ObjectName}SingleLookup
  • {TargetResourceAbbreviation}SingleLookup
  • {TargetResourceAbbreviation}MultiLookup

Examples:

  • DisabledPersonsLookup - Lookup for persons who are disabled for login
  • MRSingleLookup - Single selection lookup (MR abbreviation for Management Role)
  • BRLMultiLookup - Multiple selection lookup (BRL abbreviation for Business Role Location)

Explanation: The lookup name should indicate what object it searches for and whether it allows single or multiple selection. Abbreviations can be used to work around Windows file path character limitations.

Additional examples:

  • ActiveAccountsLookup - Lookup for active accounts
  • PersonSingleLookup - Single person selection
  • GroupMultiLookup - Multiple group selection
  • AccountStoreLookup - Lookup for account stores
  • OUSingleLookup - Single organizational unit selection (OU abbreviation)

Best practices:

  • Use descriptive names that indicate filtering (e.g., "Disabled", "Active", "Expired")
  • Add "Single" or "Multi" when the selection type is important to convey
  • Use abbreviations consistently across your project when needed for length constraints

Form Data Objects​

Form data objects should always begin with "Target" followed by the resource type. This naming convention is critical for maintaining consistency across workflows.

Pattern: Target{ResourceType}

Examples:

  • TargetPerson - Form data object for a person
  • TargetAccount - Form data object for an account
  • TargetExchangeMailbox - Form data object for an Exchange mailbox
  • TargetGroup - Form data object for a group
  • TargetBusinessRole - Form data object for a business role
  • TargetLocation - Form data object for a location

Explanation: The "Target" prefix immediately identifies this as the primary resource being acted upon in the workflow. This consistency makes it easy to identify form data objects throughout your workflow code.

Additional examples:

  • TargetAccountStore - Form data object for an account store
  • TargetManagementRole - Form data object for a management role
  • TargetResource - Generic form data object for any resource
  • TargetAzureUser - Form data object for an Azure user
  • TargetMailbox - Form data object for a mailbox

Best practices:

  • Always use the "Target" prefix - this is a standard EmpowerID convention
  • Use the full resource type name, not abbreviations
  • Match the resource type to the EmpowerID RBAC component name when possible

Naming Conventions Summary Table​

ComponentPatternExampleDescription
Form{CompanyInitial}{Verb}{TargetResourceType}FormCIEditPersonAddressFormTo name a Form, begin with the company initials, followed by the verb and target resource type, and conclude with the word "Form." For example, in the Form CIEditPersonAddressForm, "CI" represents the company initials, "Edit" is the verb, and "PersonAddress" is the target resource type.
Form > Data Source{ObjectName}DatasourceCountryDatasourceTo name a Data Source, begin with a descriptive name that effectively represents the data source, followed by the word "DataSource". For example, a DataSource named "CountryDataSource" is self-explanatory, indicating that the data source provides a list of countries.
Form > Lookup
  • {ObjectName}Lookup
  • {ObjectName}SingleLookup
  • {TargetResourceAbbrevation}SingleLookup
  • {TargetResourceAbbrevation}MultiLookup
  • DisabledPersonsLookup
  • MRSingleLookup
  • BRLMultiLookup
To name a lookup, begin with a meaningful object name and append the word "Lookup" at the end. For example, a lookup called "DisabledPersonLookup" has the word "Lookup" indicating the control, and it binds to persons who are disabled for login. You can use single or multiple words to indicate if it is a single or multiple dropdown. Additionally, you can use abbreviations like "MR" and "BRL" to keep the name concise and work around the Microsoft Windows file path character limitation.
Form > Form DataTarget{ResourceType}
  • TargetPerson
  • TargetAccount
  • TargetExchangeMailbox
To name the data object for a form, always begin with the word "Target" followed by the resource type. For example, if the data object of a form is a person, you would use "TargetPerson."

Quick Reference Examples​

Common Resource Types​

When naming components, you'll frequently work with these resource types:

  • Person - EmpowerID user identities
  • Account - System accounts (AD, Azure AD, etc.)
  • Group - Security or distribution groups
  • BusinessRole - EmpowerID business roles
  • ManagementRole - EmpowerID management roles
  • Location - Organizational locations
  • AccountStore - Systems that contain accounts
  • Mailbox - Email mailboxes (Exchange, Office 365)
  • Resource - Generic protected resources

Example Naming Scenarios​

Scenario 1: Creating a form to edit person contact information

  • Form: CIEditPersonContactForm
  • Form Data: TargetPerson
  • Lookup (if needed): PersonSingleLookup

Scenario 2: Creating a form to assign accounts to groups

  • Form: CIAssignAccountGroupForm
  • Form Data: TargetAccount and TargetGroup
  • Lookup: AccountMultiLookup and GroupMultiLookup
  • Data Source: GroupTypeDatasource (for group type dropdown)

Scenario 3: Creating a form to request a new mailbox

  • Form: CICreateExchangeMailboxForm
  • Form Data: TargetExchangeMailbox
  • Lookup: PersonSingleLookup (to select mailbox owner)
  • Data Source: MailboxDatabaseDatasource