These days, I mostly see Appian used as a platform for many different apps and workflows within their organization, rather than a monolithic single purpose system. Each client has a different combination of apps, processes, and data views that create a unique challenge in scaling their Appian program, but most clients are able to make their lives easier by following some or all of the tips below. Hopefully you can find them useful as well!
These tips are meant for developers and designers building their first 1–5 apps and can be used along with the recently released Appian Playbook which provides an excellent high-level guide to building out an Appian program.
Be strict about naming conventions
It might sound obvious, but it’s important to call the same thing, the same thing. As your Appian program scales, multiple developers will put their own unique spin on variables names, rules, constants, etc. Keep this complexity tamed by following Appian’s Standard Object Naming conventions and enforces standard variable names via regular Code Reviews.
Use APN objects across apps
Appian’s Common Object Application contains frequently used rules and constants (APN_isBlank, APN_displayGroupOrUsername, etc.) that will save you time as you develop your process-specific rules, constants, and apps. In addition, I’d recommend creating your own “APN” objects for objects that span applications so you’re not creating the same objects over-and-over again (“APN_formatDollarAmount”, “APN Human Resources Group”).
Make your apps environment-specific
Create a simple “APN_ENVIRONMENT_INDICATOR” constant with values of “DEV”, “TEST”, and “PROD” in your Dev/Test/Prod environments. Then you can customize the behavior of your applications based on environment. For example:
- Preface email subjects in Dev/Test with “*TEST*”, so they’re not confused with real notifications from Production.
- Show primary key IDs on Records in your Test environment to help report bugs via screenshots during testing.
- Build environment-specific “backdoor” paths in your process models to speed up unit and integration testing.
Add a flagArray variable to all your Process Models and SAIL forms
Create a single text array variable to use throughout your application. Trust me. Use constants to specify the particular flag at each index (APN_IS READ_ONLY_INDEX, etc.). Then you’ll be able to use the same flagArray everywhere in your application instead of passing multiple flags in and out of your SAIL forms and subprocesses. The flagArray is particularly useful when you have a mature, active app and need to control need to hide/show sections on SAIL forms without breaking in-flight processes.
Use annotations and formatting in your Process Models
- Appian is a GUI-based coding tool for building custom apps. Use the GUI to its full potential, and other developers will love you!
- You’re already describing the process in a Visio-like workflow diagram, so go ahead and use color and formatting to specific tricky business and system logic for the next developer.
- If you’re editing a commonly used process model, use a big red annotation to alert other developers not to touch the process without discussing with you.
- Use a separate color (like blue or green) when making in-flight changes to a process instance, so it clearly shows where the alteration was made.
- Explain difficult functionality or mark where a path may be deprecated in the future.
Use the Community!
Use plug-n-play apps, utilities, and plug-ins from the App Market and Shared Components. No need to reinvent the wheel! Some plugins and utilities should be deployed at the beginning of any project because they’re going to make your life, and your end-users’ lives, much better. Appian recommends several here. In addition, check the App Market for boilerplate applications or just a good starting point. Some components, like my Task Metric Utilities, can be deployed on top on *any* Appian application, no configuration necessary.
Make your Emails pretty
If your application routinely uses the ‘Send Email’ node, take 30 minutes out of your day and find a slick looking HTML template to use for all notifications. There are tons of free templates available online. It’s a simple step that will make notifications look a whole lot better than sending simple text.
Store metadata for Documents
If you’re using Appian for Document Management rather than integrating an external system, make sure to save document metadata (name, type, security level) in your database. Appian’s document management system can hold some of this information, but you’ll have more control and flexibility by storing metadata in a database instead.
Right people for the Job
Along with Appian skills, your team should have strong SQL skills and ideally some Java skills as well. SQL skills are imperative for creating performant database Views from summary reports and other display UIs. Java skills are important for plugin development and custom integrations if necessary. Lastly, make sure your team stays as close as possible to your end-users. The closer that the Appian application mimics the real-life process in nomenclature, functionality, and general utility, the better.
Hope that helps and feel free to reach out if you found the post helpful!
Thanks,
Corbin
Originally published at nav-labs.com.
