Use this checklist throughout your development cycle to ensure application success and reduce technical risk. Each section provides recommendations for when and how often the checklist should be used.
Run through the relevant subsections of this checklist during the development and peer review of all new features.
The application security summary has been reviewed for every object.
☐
A unique PREFIX and an object naming convention has been defined for each application and observed for all objects.
All objects have useful names and descriptions.Inline commenting is leveraged where applicable to describe important or complex code blocks.
The "PREFIX Viewers" (or "PREFIX Users"), "PREFIX Designers", and "PREFIX Administrators" groups for each application have been created and used to grant access to all objects.
All objects in the application - including the application itself - have the following security settings:
The "PREFIX Administrators" group is set as Administrator
The "PREFIX Users" group is set as Viewer
BY default, all other users do not have access
The Health Dashboard does not contain any warnings or recommendations.
Appian Health Check results are reviewed and addressed as part of each sprint.
The application is built as a record-centric application. Record types are used to represent the business entities.
Record types have data sync enabled whenever possible.
The domain model of the application is designed as a set of record types with relationships.
Secure the records using record-level security rules when appropriate. Use constants instead of hard-coding condition criteria in these rules.
When enabling the “Show search box” option:
Queries and integration rules are not called as local variables that refresh always (or refresh on a short time interval).
Queries to data stores or records always use a PagingInfo that has an explicit batchsize value. Do not use -1.
Ensure that only the data that is needed to support the interface/rule is queried for. No excess data should be pulled into memory.
There is no looping over queries, integrations, etc. wherever possible. Pay close attention to this when building grids or record lists.
Interfaces and expression rules open in Interface Designer without errors.
Interfaces have useful test inputs saved as Default.
Expression rules have at least 2 test cases:
Interfaces, expression rules and functions are invoked using keyword syntax (e.g. textInput: someValue).
Rules are properly formatted and readable.
Comments are available in-line in SAIL for every major code change in interfaces and expression rules. A sample format is /* STORY_NUMBER: meaning of the code change */
When invoking rules recursively, ensure that the recursivity is not infinite. Add several unit tests to your rule to account for all permutations.
All SAIL interfaces are compatible with automated functional testing by following the SAIL design best practices described in the FitNesse For Appian Best Practices guide.
The value of the constant is called out in the description, along with a description. For example: PREFIX_STATUS_VALID represents a constant for the application PREFIX related to the value of the status “VALID”.
A constant is used whenever a value is repeated.
Constants are reused: one constant for each single unique value, no duplicate.
Process model has labeled swim-lanes with default assignment.
Process model display name is set and is dynamic. It includes a key attribute that differentiates it from other instances of the same process model.
All process flows have been tested and no errors occurred.
All models have custom Alert settings configured using groups.
Processes that contain user input tasks or a significant portion of log: Archive after 3 days. Everything else: Delete after 0 days.
Process models are split into sub-processes to compartmentalize sets of functionality and large cumbersome process models are avoided.
Always use the Start Process smart service to start a related process unless
The related process must be activity-chained to a User Input smart service for cohesive UX. In this case, use the Sub-Process smart service configured as synchronous.
The related process must run as a synchronous process to meet business requirements. In this case, use the Sub-Process smart service configured as synchronous.
The related process must return process variables back to the parent process as outputs. In this case, use the Sub-Process smart service configured as asynchronous.
Models contain no more than 30 nodes.
Models contain no more than 50 process variables.
XOR gateways are used in front of MNI nodes to check for empty/null values.
Process flow will always reach at least one terminating end event.
Process-to-process messages are targeted to a specific process instance using PID.
All complex logic is documented using annotations (anything that isn't obvious).
All external integrations are contained in their own subprocesses to minimize the impacts of the external systems changing their interfaces. E.g. anything other than query rules and data stores should be encapsulated.
Only use Activity Chaining when needed to support a cohesive user experience.
If the external integration points are using CDTs to exchange data (such as integration with web services), use these CDTs locally within the integration process models or rules and create business CDTs to be used by the rest of the application. This prevents changes in external systems data structures from having widespread impacts in the application.
Best practices for creating memory efficient models have been followed.
Design short-lived processes to perform actions and maintain the data.
Ensure there is no way to unintentionally loop through a smart service node (db write, create document, etc).
Nodes are named with verb-noun format (e.g. Review Purchase Order).
Task display name is set and dynamic.
Every SAIL form node has all inputs specified as process variables or activity class parameters.
All XOR/OR gateways have a single incoming flow.
All outgoing flows from a gateway are labeled.
XOR gateways are used instead of OR.
Node inputs do not make the same query call more than once.
CDTs are not passed by reference between parent and sub-process.
Looping functions are used instead of Multiple Node Instances where possible.
On the Other Tab for Forms, check the "Delete previous instances" and do not check “Keep a record of the form”.
Use rules and constants instead of hard-coded values in the process nodes.
All groups are created as Custom groups.
If the group is intended to be selectable in a user interface, ensure that the Visibility setting is configured properly.
After deployment to production, do not delete groups. The group identifiers are reused when groups are deleted which can affect the security and behavior of an application.
The CDT name should closely match the underlying database table/view name with the appropriate formatting described above.
All CDTs stored in a Data Store expose a primary key field.
All CDTs contain no more than 50 fields (this does not apply for CDTs created by web services).
All CDTs contain no more than 1 level of nested CDTs (this does not apply for CDTs created by web services).
No CDT contains nested lists that are not explicitly defined as separate CDTs (e.g. a nested list of Text).
Application specific contents are stored within an application specific KC and folder structure (or at least not in the Default Community).
All reports are stored in the application folder structure (not in the System Reports folder).
Folders created in process have specific security defined when required.
Run through this checklist:
There is a consistent UI throughout the application in terms of
Interface layouts
Position of key “widgets”
Look and feel
All actions, related actions, records, reports, and published applications have useful names and descriptions.
Clicks, key presses, and scrolling has been minimized.
No performance findings highlighted by the Appian Health Check.
All acceptance criteria are met or updated/deleted.
Functionality can be run successfully.