Create Appian Object Hierarchies

Appian object hierarchies dictate how to organize the artifacts within an application, including:

• Groups

• Process Models

• Rules and Constants

• Documents

Each of these objects are organized in separate content hierarchies. They must be organized in a fashion easily searchable and navigable by any designer working on the application.

The following recommendations offer a good starting point for most Appian environments.

Appian Group Hierarchy

Appian groups are responsible for driving task assignment and security throughout the entire application. 

General Guidelines

• Keep group names unique.
  • Appian allows for duplicate group names however this can complicate selecting groups using the group picker and can lead to exceptions when using expressions or API calls that assume that group names are unique.
• Avoid creating custom group types unless there is a strong need/requirement.
  • Custom group types allow Appian Administrators to associate particular attributes with groups created from the custom group type. While there are good uses for group attributes, support and ease-of-use within Appian is still limited and not a focal point of the application at the current time. If group attributes are required, ensure that Appian can natively support the client use case and/or investigate the use of an external database to store additional attributes for easy update/retrieval.
• Only create the groups necessary for task assignment or security.
  • Do not create groups to mirror the client organization tree. It is not important to create all groups ahead of time. In fact, it may be best to employ a create as you go approach when designing the application.
• Keep group names short but descriptive and use the application prefix
  • Avoid starting all group names with the same prefix and avoid particularly long group names if possible. Keeping group name prefixes unique and group names short will greatly help usability for application designers and end users (especially when using group pickers). Note: if a group is *only* used for a particular application and would not be utilized by any other application, then it is a good practice to use a simple (up to 3 letters) prefix when naming these groups (i.e. <APP> Document Approvers).
• Flat group structures can be a good option.
  • There can be maintenance benefits to creating a group hierarchy but this is not necessary for most applications.

Application Specific Guidelines

• Create an All Users group for each application called <APP> All Users. The <APP> All Users group should include all users in the Appian environment that should have access to this application. 
• Create an Administrators group for each application called <APP>_Administrators. The <APP>_Administrators group should only include the users that are going to manage the application in the production environment. These users will have access to all objects and running processes of the application.
• Use the same prefix for all groups of a specific application
• A good starting point for an application specific group hierarchy is represented below. In this example, "APP" is the application prefix used to name all objects belonging to the application.
  • APP All Users
    • APP Administrators
    • APP <Role 1>
    • APP <Role 2>
    • ...

Appian Process Model Hierarchy

• Process models should be organized by application based on the application that they belong to.
• Create a top level process model folder per application.
• If necessary, create sub folders to organize process model into modules.
• Secure the process model folders to grant Admin access to the APP Administrators group

Appian Rules and Constants Hierarchy

• Rules and constants should be organized by application based on the application that they belong to.
• Rule and Constant names should be prefixed with the department and application identifiers or with COMMON for common rules. 
• Rule and Constant names should be descriptive to promote reuse.
• Use the following folder hierarchy as a starting point:
  • APP Rules And Constants
    • APP Constants
    • APP Interfaces
    • APP Queries
    • APP Rules
• Constant names should be all UPPERCASE e.g. APP_BUSINESS_THRESHOLD.
• Rules should be sentence cased e.g. APP_SearchClientsById.

Appian Document Hierarchy

• Documents should be organized by application based on the application that they belong to.
• Create one knowledge center for the documents that make up the application such as templates, images, etc.
  • Secure the knowledge center to grant Admin access to the APP Administrators group
  • In most cases, users should have read only access to this knowledge center.
  • The following is a good starting point for such a knowledge center:
    • APP System Knowledge Center
      • APP Templates
      • APP Images
      • APP Portal Reports
      • ...
• Create a second knowledge center for the business documents that are uploaded by end users or generated by the system as part of the application flow. 
  • Secure the knowledge center to grant Admin access to the APP Administrators group
  • The security settings on this knowledge center are critical to prevent users from accessing documents that are restricted.