Article

Why Process Automation is Right for Your Business

Devon Lee — Fri, 30 Jan 2026 21:09:09 GMT

Current Revision posted to Article by Devon Lee on 1/30/2026 9:09:09 PM

Organizations are transforming at a breakneck pace, driven by rapidly evolving consumer behavior and expectations. New, digitally enabled businesses are upending entire industries and the COVID-19 pandemic has only accelerated the trends. According to an executive Global Survey done by McKinsey, more than half of respondents said they were “investing in technology for competitive advantage or refocusing their entire business around digital technologies.” Compare that to the same survey done pre-pandemic in 2017, where only around 10% of respondents held the same view of technology.

The problem is most businesses continue to rely on legacy enterprise systems. These systems are often complex and difficult to change. Over time, they often include patched or jerry-rigged measures to address a myriad of issues. With all this change, one thing is clear—you can’t rely on inflexible technologies and business practices. You need adaptable systems that can meet the needs of today and the demands of tomorrow.

Is traditional software development up to the task?

Organizational success has become increasingly dependent on technology. Even “non-tech” companies now succeed or fail based on the capabilities of their digital infrastructure. However, the typical technology stack is often complex and opaque. It’s hard to use and years worth of ad-hoc changes have made it even harder to revise. This is only made worse by slow and expensive software development practices.

In today’s technological climate, the ability to quickly develop and implement new processes is essential. Whether you’re a hotel providing touchless check-in or a retailer fostering a more efficient and personal online shopping experience-—brands that empower customers with technology are being rewarded. This trend has only been accelerated further by the onset of the pandemic, where agility and adaptability have in some cases meant the difference between thriving and just surviving. If you were quick to put in place contactless protocols, you could get back to work faster than those with inflexible systems.

Given this increasing need for agile and flexible software development, traditional methods of hand-coding software can’t keep up. The traditional software development model consists of large, centralized teams of specialized developers. These teams work within highly planned and rigid processes and fail to adequately address the complex automation needs of today's digital enterprise. If you're stuck with outmoded or rigid legacy processes, you won't be able to adapt to your users changing needs and may risk losing them. Compounding the problem are a complex set of circumstances, including:

Unprecedented new operating environments. The COVID-19 pandemic ushered in a world of continuous disruption and adaptation. It forced organizations to create processes for remote work. It also called for new safety, testing and tracking protocols.
Changing regulatory requirements. From environmental protections to accounting standards—new rules and regulations result in costly workflow modifications.
Evolving expectations. Customers and employees expect high-quality, streamlined and intuitive user experiences. The bar is now set by their favorite brands at home, rather than those at work. Companies must continually enhance the customer journey by leveraging data and digitizing functions.
Global growth opportunities. Global markets enable organizations to sell and source materials in new territories. Technology is not only making new products and services possible, but also changing how you market and deliver them. But, without the time and resources to invest, businesses risk missing out.

Navigating all this uncertainty requires more streamlined, automated digital workflows. And this must be done as rapidly and cost-effectively as possible.

Low-Code: Flexible, Resilient and Adaptable

To thrive in this new reality, enterprise software today must be flexible, resilient and adaptable. You need customizable automation that can change according to dynamic needs. You also need automated workflows that are custom mapped to unique goals and real-world challenges, not just the most common scenarios. Most of all, you need to increase speed and lower the cost of development.

Fortunately, low-code development platforms reduce the burden of building enterprise applications. Meaning you can now build apps and streamline workflows faster and cheaper than ever before. Low-code lets you leverage existing technology investments, and extend capabilities. It reduces buildout time and cost, and enables you to effectively automate functions to compete in this new paradigm. An Economic Impact Study conducted by Forrester found that customers using Appian’s low-code platform:

Accelerated application creation by 17x
Improved time-to-value of applications by 50%
Realized a 389% return on investment (ROI)

Those outcomes were made possible by two distinct advantages low-code offers to developers: Speed and Ease of Use. Low-code allows developers to work rapidly by selecting from a library of ready-made tools or empowering them to make their own reusable tools. In addition, low-code removes the barrier to entry to software development. Rather than each developer needing a solid command of Java, HTML, CSS, PHP, SQL (not to mention third party API frameworks ), each team member only needs to know Appian, which creates bandwidth for what’s most important: solving real business problems.

At its core, low-code does away with much of the time and resource intensive high-code development requirements. Appian pioneered and continues to lead the low-code development space by providing best-of-breed integrated development tools, in addition to a full suite of tools designed to help you unify your data, build apps, and automate your business.

Tags: Vision

Innovate with Process Automation

Devon Lee — Fri, 30 Jan 2026 21:07:06 GMT

Current Revision posted to Article by Devon Lee on 1/30/2026 9:07:06 PM

To be competitive today, it’s not enough for businesses to be efficient; they also need to innovate according to their own unique vision. They need to offer dynamic products and services that can respond to the distinct demands and requirements of their users. However, building a new product or service is a time and resource intensive undertaking. This is even more pronounced when developing solutions that don't fit nicely into pre-established product delivery pipelines. Manual tasks, inflexible processes and complicated business rules all get in the way of offering unconventional or game-changing product lines.

Innovation, by definition, requires some coloring outside the lines. And this is where low-code can make all the difference, by helping businesses automate their processes and integrate more flexible delivery models.

Innovation for differentiation

In the sometimes conservative and highly regulated world of finance, innovation can be hard to come by. But institutions with an eye towards digital transformation are increasingly differentiating themselves in a highly competitive market. Let’s take a look at SEB Investor Services, one of the leading providers of asset servicing to institutional investors in the Nordic region, to see how low-code drives innovation.

SEB saw an opportunity to offer its clients services outside the traditional securities most banks provide, namely shares, bonds, derivatives, and funds. They wanted to add alternative assets–wind and solar, private equity, venture capital holdings–to their portfolio, so as to better serve the diverse needs of their clients. In the past, SEB offered relatively few alternative assets due to the manual labor and high degree of operational difficulty required to provide the service. They needed to find a way to automate the handling of these assets, without having to bring in a full team of developers to create and maintain the service.

That’s when the SEB team identified low-code as the perfect solution to quickly and efficiently move forward with their plan. Using the Appian platform, they were able to reconfigure and automate complex business rules, as well as the unique workflows and data structures associated with alternative assets. In an interview given to PostTrade 360°, SEB Product Manager Frederik Söderlund described the process of using low code to realize the project:

The big projects cost big money – with large project groups, consultants and testing. But when you start from a blank sheet today, using new technology based on blocks that you assemble in lego style, with pre-defined integrations and self-testing capabilities…it gets so much easier.

Fredrik Söderlund, Product manager for portfolio solutions at SEB Investor Services/LCFI

In addition to automating the handling of alternative assets, SEB was also able to employ AI-powered IDP (Intelligent Document Processing) to help extract and interpret investment data. This holistic approach enabled them to not only increase the number of alternative assets available to their clients, but to maximize value from returns on those investments. By partnering with Appian, SEB was able to take one of finance’s least standardized processes and unlock new, value-added product offerings from it.

Disruptive innovation

Disruption shouldn’t be a business goal in and of itself. But innovation often has the side effect of disrupting those arenas that are no longer providing an optimal experience. Since the advent of ridesharing companies, the commonly held belief was that congestion and pollution would decrease as more single drivers opted for these services. However, a study conducted by Researchers from the University of Kentucky and the San Francisco County Transportation Authority found that transportation network companies (TNC’S) were actually the largest contributor to increased congestion in cities like San Francisco.

Enterprise Holdings, Inc, manager of the largest and most diverse privately-owned fleet of vehicles in the world, identified an opportunity to innovate within the ridesharing industry. The plan was to target a traditionally underserved market of vanpool commuters, namely people traveling to work in groups of more than 3 or 4. The goal was to provide these commuters with a lower-cost, more environmentally friendly commuting option.

However, existing systems within the company could not accommodate a new business with a radically different operating model and workflow. Building a custom application using traditional methods would have taken years, causing Enterprise to miss their window of opportunity. Using Appian, Enterprise was able to realize this vision and create Commute, the company’s vanpooling service, in just 4 months.

Commute programs are organized by an employer and typically consist of 4 to 15 coworkers traveling together. Commuters coordinate a central meeting location, board a late-model, low-mileage van or SUV from the company’s fleet, and take turns driving to and from work. This gives commuters time to read, relax, catch up on some work, or even stream their favorite shows with WIFI enabled vans.

We adopted Appian's platform for Enterprise Rideshare because it combines the best of business process management, social business, mobile access and cloud deployment. The result is a truly modern business management platform that supports our objective of providing commuters with a smarter, better way to get to work.

Ryan Johnson, Assistant Vice President of Enterprise Holdings

Commute not only helps workers reduce the financial burden of commuting, but also lets them arrive at work less stressed, leading to higher productivity. After partnering with Appian, Commute has scaled to operate more than 11,000 vanpools in 45 states. It removes more than 40,000 vehicles off the road every day and eliminates an estimated 900 million commuter miles annually. To top it all off, the program also reduces more than 695 millions pounds of carbon emissions annually.

We’ve seen how low-code can be a driver for innovation, whether in more historically conservative fields such as finance, or in burgeoning industries such as ridesharing. Low-code enables businesses to work more quickly, efficiently, and cost effective. Dynamic business conditions and evolving user demands will always put pressure on businesses to innovate. With low-code integrated into their digital strategy, imaginative organizations can respond quickly and decisively, while continuing to push the envelope on their personal strategic vision.

Tags: Vision

Process Automation Team Essentials

Devon Lee — Fri, 30 Jan 2026 21:06:28 GMT

Current Revision posted to Article by Devon Lee on 1/30/2026 9:06:28 PM

One of the most common questions we receive focuses on how to structure an organization for low-code success. There isn’t a one-size-fits-all answer to this question, but we do have a few guidelines for getting started. The most important part is thinking of your Appian-trained workforce as a team, with mutually supportive roles and responsibilities across the organization.

At Appian, we think a successful team is a combination of a few select roles that each play an important role in a project’s success:

Leaders
Planners
Builders
Administrators

Let’s dig a little bit deeper into each of these team roles, why they are important, and what they need to know.

Appian Leaders

For our purposes, leaders include business stakeholders, managers, or executives who need awareness of low-code automation capabilities but aren't heavily involved in the development process. They are, however, stakeholders and decision makers responsible for an organization’s success. They often control the budget, people, and determine the desired outcomes of projects. To be successful, these leaders need to understand the capabilities of Appian and how it can solve their problems.

Leaders also need to understand how to source, train, and structure their teams for ongoing success, and they’ll usually want to know what pitfalls to look out for when automating portions of their business.

See our Vision pillar for resources geared towards Appian Leaders.

Appian Planners

The planner role defines the processes to be automated, prioritizes development efforts, and ensures coordination with other business units. The most common job titles we see functioning in the planner role include business analysts, product owners, project managers, scrum masters, and UX designers. Some organizations have distinct team members assigned to each role, while others may have a single individual functioning across multiple roles. At a minimum, you should plan to include both a product owner and an analyst as part of your Appian team. This will ensure your organization is positioned for success.

Appian planners need a strong understanding of the Appian delivery methodology and a basic understanding of how Appian objects come together to make applications. See our Delivery pillar for more resources geared towards Appian Planners.

Appian Builders

Builders, or developers, are the core of any Appian delivery team. Their primary job is taking requirements produced by the analysts, prioritizing them with the product owner, and converting them into applications using the Appian process automation platform. Functionally, the role of an Appian builder can be broken down into the following positions:

Low-Code Developers
Lead Developers
Quality Assurance

Appian strongly recommends a Team of 3 structure for most projects, with larger projects or initiatives distributed across multiple teams. Each team should be cross-functional in so much as any member of the team can take on any task when needed. Naturally, some team members will be stronger in certain skills than others, but we’ve found that high-performing, multi-disciplinary teams are best suited for success.

For example, a low-code developer often falls into the “Developer and…” paradigm. This means that a particular team member might fall into a dual role as a low-code developer, in addition to acting as an architect, scrum master, UX lead, or test manager. When building these small cross-functional teams, it’s important to look for team members that have skills outside of their primary role or function. Whether that’s an interest in data models, integrations, or process mining, looking out for complimentary skills is the best way to establish a versatile low-code team.

Administrators

Administrators own responsibility for the Appian system and supporting infrastructure. This includes overseeing server admins, database administrators, IT staff, or anyone supporting the application’s backend. Administrators are most often concerned with the security implications of the Appian platform and how it interacts with their internal systems. This includes things such as data management, web APIs, user accounts and more.

Although administrators aren’t usually involved in development themselves, they work closely with lead developers to define technical requirements and boundaries. To this end, administrators should pursue a basic level of training to better understand the terminology and underlying infrastructure of the Appian platform.

Application Administrators

Application Administrators are employees of the customer organization responsible for the maintenance and support of individual applications. They’re typically in charge of user management, performing basic clean-up and housekeeping activities, and serve as the first layer of support to triage tickets and issues.

At a high level, Application Administrators understand how Appian objects interact with one another to form an application, but aren’t developers themselves. They perform basic troubleshooting activities, and are knowledgeable on navigating Appian support systems to get resolution on more complicated issues. Application Admins are also familiar with tools including Health Check, Health Dashboard, and MyAppian.

To support this role, we developed the Appian Application Administrator course, available through Appian Academy.

Tags: People

Shared Object Management Overview

joel.larin — Wed, 29 Oct 2025 14:20:10 GMT

Current Revision posted to Article by joel.larin on 10/29/2025 2:20:10 PM

Overview

This document provides guidance on what shared objects are, how to identify them, how to secure them and how to update them in a manner that is safe and responsible. When used with care, shared objects provide a layer of reusable components for the entire platform to fast forward the development of every application.

Common objects are those that are used across the platform in multiple applications. They could provide generic, routinely-used functionality for many applications or they could be more specialized and used for a specific set of applications only.

For example, a user sync module that pulls user information from Workday would fall into the first category, while an Engagement record will fall into the latter. Avoid objects with complex or specific business logic unless they apply to all referring applications and aren’t likely to differ between applications in the future. In general, the more well defined and structured the inputs and outputs of an object are, the easier it will be to reuse amongst different applications. The rules for which objects to place into a common objects application can differ from one organization to another, however it is important to consider the value the component will provide compared to the additional time to maintain, test, and coordinate among groups utilizing the object.

In some situations, having multiple common object applications, each specific to their scope, will make managing changes easier for those who utilize them. As an example, a department may have multiple applications to manage new product approvals, customer onboarding, and periodic customer review processes which share common data objects, expressions, and integrations. Some of those components may be specific to the department and others are used globally. For each common objects application that your organization decides to create, ensure the following are documented:

Description of the purpose and scope
Owner or owning group
Implementation usage instructions
Who to notify when updates are made

Object Types

Object type	Criteria	Example
Expressions Decisions	Logic containing reusable functionality	Email address validation Mailing address formatting Display name formatting
Data Types Data Stores Query Rules Constants	Reference data across applications	List of States/Countries User details
Interfaces	Common interface sections	Mailing address input form User details input form
Web APIs	Reference data exposed externally	User details
Records	Records referenced by or containing data from multiple applications or synced records representing reference data	Study Engagement
Process Models	Logic containing reusable functionality	User synchronization
Connected Systems Integrations	Reusable connections to external systems	Transfer documents

Identification and Cataloging

The identification of common objects is the responsibility of the application development team and the Center of Excellence (CoE). Some heuristics for identifying common objects could include:

Is the functionality going to be accessed by all platform users?
Are other applications going to leverage the same functionality? e.g. vendor search?
Is the functionality agnostic of the application it is in? e.g. a list of countries
What is the potential scope of a common object; eg. Department, Region, Global

These questions can be asked before, during and after the development cycle, but the sooner common functionality is identified the easier it is to classify it and leverage it across the platform.

Once the team identifies the object(s), they should be moved to the appropriate application and renamed with the appropriate application prefix. Detailed descriptions for Appian objects are important to ensure that changes do not break the contract between the shared object and the corresponding dependent object. For expressions and interfaces, ensure common objects have test cases defined so that during updates, they can be tested for backwards compatibility. Rule inputs should also be given descriptions so that Designers can easily understand their intended use. Teams working on new applications should always consult the Common Objects applications in order to identify any functionality that could be reused. Proper naming conventions and descriptions will make these objects easier to search and discover.

Security and Ownership

Since common objects are shared between different applications, changes to these objects can have a wide impact. Changes that benefit one app could potentially break another. Therefore, updates to common objects need to be taken with care after sufficient impact analysis.

In programs with multiple teams, we recommend securing the objects to a specific designer group (and revoking sys admin access from designers). In such situations, while all objects need to have an admin group defined (see Health Check for more details), common objects especially need to have correct security set up with one group as the object admins and other designer groups as viewers – so these objects can be used but not edited.

Common Object Use and Maintenance

Using a common object is very easy – just reference it in your application. Note that if the common object version you wish to utilize has not been deployed to your desired environment already, you may need to use a separate package to deploy it, if it is only part of the common object application but not your own.

When an object needs to be edited, make a change request to the owners. Where appropriate, consider notifying the impacted teams if the updates will result in changes to the end user behavior or will require consumers of the common objects to opt into the new functionality being developed. Who makes the change depends on your organization (see Example Process) but we recommend that owners delegate the edits to the change requestor (application team). Appropriate testing and reviews should occur before promoting to higher environments. An extra emphasis should be placed on regression testing to ensure the changes will be backwards compatible.

Example Process

Steps to Modify Common Objects

When an object is modified in a common app, follow the below steps:

Request to make a change from the object owner(s).
Before making the change, check for dependencies on the object to see which teams could be impacted by the rule modification. Reach out to the associated owners to ensure the change is compatible before proceeding.
The owner grants edit access to the application(s).
If a common object needs to be modified that already has changes in progress, check to see if the change has already been deployed throughout the environments. More complex objects, like records, have a higher likelihood of a change in progress. If that is the case, reach out to the developer associated with the object and ensure the proposed changes are compatible before proceeding. Other measures may have to be taken, e.g. feature toggles, to get the changes deployed without breaking precedents.
Owner revokes edit access to the application(s).

Tags: Delivery, Architecture

Shared Object Management Overview

joel.larin — Wed, 29 Oct 2025 14:19:56 GMT

Revision 7 posted to Article by joel.larin on 10/29/2025 2:19:56 PM

Overview

"Common objects are those that are used across the platform in multiple applications. They could provide generic, routinely-used functionality for many applications or they could be more specialized and used for a specific set of applications only. "

Description of the purpose and scope
Owner or owning group
Implementation usage instructions
Who to notify when updates are made

Object Types

Object type	Criteria	Example
Expressions Decisions	Logic containing reusable functionality	Email address validation Mailing address formatting Display name formatting
Data Types Data Stores Query Rules Constants	Reference data across applications	List of States/Countries User details
Interfaces	Common interface sections	Mailing address input form User details input form
Web APIs	Reference data exposed externally	User details
Records	Records referenced by or containing data from multiple applications or synced records representing reference data	Study Engagement
Process Models	Logic containing reusable functionality	User synchronization
Connected Systems Integrations	Reusable connections to external systems	Transfer documents

Identification and Cataloging

The identification of common objects is the responsibility of the application development team and the Center of Excellence (CoE). Some heuristics for identifying common objects could include:

Is the functionality going to be accessed by all platform users?
Are other applications going to leverage the same functionality? e.g. vendor search?
Is the functionality agnostic of the application it is in? e.g. a list of countries
What is the potential scope of a common object; eg. Department, Region, Global

These questions can be asked before, during and after the development cycle, but the sooner common functionality is identified the easier it is to classify it and leverage it across the platform.

Security and Ownership

Common Object Use and Maintenance

Example Process

Steps to Modify Common Objects

When an object is modified in a common app, follow the below steps:

Request to make a change from the object owner(s).
Before making the change, check for dependencies on the object to see which teams could be impacted by the rule modification. Reach out to the associated owners to ensure the change is compatible before proceeding.
The owner grants edit access to the application(s).
If a common object needs to be modified that already has changes in progress, check to see if the change has already been deployed throughout the environments. More complex objects, like records, have a higher likelihood of a change in progress. If that is the case, reach out to the developer associated with the object and ensure the proposed changes are compatible before proceeding. Other measures may have to be taken, e.g. feature toggles, to get the changes deployed without breaking precedents.
Owner revokes edit access to the application(s).

Tags: Delivery, Architecture

Appian Usage Insights / Appian License Tracking FAQs

joel.larin — Tue, 10 Jun 2025 23:12:18 GMT

Current Revision posted to Article by joel.larin on 6/10/2025 11:12:18 PM

Why does my application package include something called “Appian License Tracking”?

A recent update to the application led to this name change. The name used to be “Appian Usage Insights” but is now “Appian License Tracking.” The previous name persists on the AppMarket posting for recognition purposes.

The application tracks license utilization and may, in future iterations, more closely track application usage based on log availability within Appian.

How do I install the apps?

The bundled Appian License Tracking Usage Insights Installation Guide describes how to do this.

How do I upgrade to the latest version of the apps?

The bundled Upgrade Notes document describes how to do this.

How should I use the apps?

The bundled Appian License Tracking Quick Start Guide describes how to do this.

How does the app deduplicate users across environments?

Users are identified by distinct username. Their group membership and logins are considered across all environments based on the same username. For example, john.smith in Environment A is considered to be the same user as john.smith in Environment B, but not the same as john.smith@acme.com in Environment C.

I’ve run analysis on a collection run but the configuration was wrong. What can I do?

You can modify the configuration (business entities, license pools and groups, license types etc) and rerun analysis on the latest collection run as many times as you need to get the configuration right. You can only run analysis on the latest collection run, so once you load the next collection run (a few weeks later) then any further configuration changes will only apply to analysis of that next collection run data.

After my latest collection run, why do all license pools have zero allocated licenses?

After each new collection run you need to run analysis again on that latest collection run. The majority of the reports are based on the analysis of the latest collection run (except for the capacity planning report and user logins over time), so will not display any data until analysis has been run on the new collection.

How do I know which version of the app I am running?

From v1.1.0, a constant was introduced in both the Collector and the Reporting apps to display the app version. This has been updated in v2.0.0 to the following based on application name updates.

Collector App: LRDC_APPIAN_LICENSE_REPORTING_DATA_COLLECTOR_VERSION
Reporting App: ALR_APPIAN_LICENSE_REPORTING_VERSION

Information for v1.1.1 and older versions can be found below:

For the Reporting app, if the constant LMA_R_APPIAN_USAGE_INSIGHTS_REPORTING_VERSION does not exist in your app, you are either running v1.0.0 or v1.0.1. In this case, if your reporting database includes the Stored Procedure LMA_SP_USERS_BY_LICENCE_TYPE, then you are running v1.0.1.

For the Collector app, if the constant LMA_R_APPIAN_USAGE_INSIGHTS_COLLECTOR_VERSION does not exist in your app, then you are running v1.0.1 (which is identical to v1.0.0 as the Collector app did not previously change).

How should I configure reporting to see details per app but also grouped at business unit level?

From v1.1.0 onwards the Application Quick Start Guide describes how to do this.

How do I configure flat app thresholds?

From v1.1.0 onwards you can do this via the related action within any license type record. See the Application Quick Start Guide for more information.

Do you have examples or scenarios of how to set up the business entities?

Business entities are a fairly flexible concept that allow you to model usage in the most appropriate way for your business. A standard approach - that provides an overview at business unit level while allowing visibility on a per-app level too - would be to configure business entities for your organisation's larger business units, and then model the apps that belong to those business units as entity license pools. For this you would create one or more license types per app.

For example, you might configure "Finance" as a business unit, create "Fin App1 Enterprise Users", "Fin App2 Enterprise Users" and "Fin App3 Enterprise Users" as license types, and map those to the Finance business entity by creating an entity license pool for each license type within the Finance business entity. For each of those entity license pools, you would configure the groups that allow you to identify users of each of those apps (so the entity license pool for "Fin App1 Enterprise Users" might be the group "Fin App1 All Users", for instance).

When you find users that still end up in the Default entity, it's because you haven't mapped a group for them in your Business Entity - license Pool structure. The aim is to end up with no one left in the Default pool, so you know you have configured things correctly. This can take several iterations.

Why do I have to upload collection data from all of my environments at once?

Usage analysis and the resulting reports are based on a snapshot of usage across all in scope environments at the same time. Therefore, for each new collection run loaded into the reporting application, a collection for every active environment is required. These collections should generally have all been run on the same day, or close enough.

From v1.1.0 it is possible to deactivate an environment so that no further collections need to be uploaded for it. This would be used where an environment that was being reported on is no longer being used.

Can I use a non-production environment to host the reporting app?

You should consider whether your organisation allows the data that the collector application collects to be stored in a non-production environment. Additionally, as you use the application and the data stored in the reporting application grows, you should consider how you manage capacity in your chosen non-production environment.

As with any App Market app, clients are responsible for testing these apps in their own environments. When rolling out the Appian License Tracking applications within your organization, ensure that the apps are tested in your non-prod environments first according to your usual testing and release procedures.

How can I export the reports?

Currently (v1.1.0) the only export functionality included is the high level Usage by Business Entity report, which can be exported via the "Download usage by business entity" download link on the Usage Reports > Usage By Business Entity report.

How do you report on non-prod and prod licenses separately, where users need to have one license per environment?

Install the reporting app once per environment tier - e.g. a Dev reporting component, one for Test, one for Prod etc. Load only Dev environment collections into the Dev reporting component and so on.

How do I configure the collector app to gather login information for the last year?

The data collection component will collect a maximum of the last 30 days worth of login information. If you have run the collector in the last 30 days, it will collect the login information since the last time it ran. Over time as the collector is run (at least every 30 days) and the collections are loaded into the reporting component, you will build up login data across a longer period. The application doesn't support collecting older, compressed login audit data. This doesn't prevent the allocation of users to license pools (which is based on the most recent group membership collections). But it does mean that the login information displayed in the app will only become more meaningful as collections are built up over time.

Tags: monitoring

Appian Usage Insights / Appian License Tracking FAQs

joel.larin — Tue, 10 Jun 2025 23:10:55 GMT

Revision 9 posted to Article by joel.larin on 6/10/2025 11:10:55 PM

Why does my application package include something called “Appian License Tracking”?

The application tracks license utilization and may, in future iterations, more closely track application usage based on log availability within Appian.

How do I install the apps?

The bundled Appian License Tracking Usage Insights Installation Guide describes how to do this.

How do I upgrade to the latest version of the apps?

The bundled Upgrade Notes document describes how to do this.

How should I use the apps?

The bundled Appian License Tracking Quick Start Guide describes how to do this.

How does the app deduplicate users across environments?

I’ve run analysis on a collection run but the configuration was wrong. What can I do?

After my latest collection run, why do all license pools have zero allocated licenses?

How do I know which version of the app I am running?

From v1.1.0, a constant was introduced in both the Collector and the Reporting apps to display the app version. This has been updated in v2.0.0 to the following based on application name updates.

Collector App: LRDC_APPIAN_LICENSE_REPORTING_DATA_COLLECTOR_VERSION
Reporting App: ALR_APPIAN_LICENSE_REPORTING_VERSION

Information for v1.1.1 and older versions can be found below:

How should I configure reporting to see details per app but also grouped at business unit level?

From v1.1.0 onwards the Appian Usage Insights Quick Start Guide describes how to do this.

How do I configure flat app thresholds?

From v1.1.0 onwards you can do this via the related action within any license type record. See the Appian Usage Insights Quick Start Guide for more information.

Do you have examples or scenarios of how to set up the business entities?

Why do I have to upload collection data from all of my environments at once?

Can I use a non-production environment to host the reporting app?

As with any App Market app, clients are responsible for testing these apps in their own environments. When rolling out the Appian Usage Insights applications within your organisation, ensure that the apps are tested in your non-prod environments first according to your usual testing and release procedures.

How can I export the reports?

How do you report on non-prod and prod licenses separately, where users need to have one license per environment?

Install the reporting app once per environment tier - e.g. a Dev reporting component, one for Test, one for Prod etc. Load only Dev environment collections into the Dev reporting component and so on.

How do I configure the collector app to gather login information for the last year?

Tags: monitoring

Appian Usage Insights / Appian License Tracking FAQs

joel.larin — Tue, 10 Jun 2025 23:09:42 GMT

Revision 8 posted to Article by joel.larin on 6/10/2025 11:09:42 PM

Why does my application package include something called “Appian License Tracking”?

The application tracks license utilization and may, in future iterations, more closely track application usage based on log availability within Appian.

How do I install the apps?

The bundled Appian License Tracking Usage Insights Installation Guide describes how to do this.

How do I upgrade to the latest version of the apps?

The bundled Upgrade Notes document describes how to do this.

How should I use the apps?

The bundled Appian License Tracking Quick Start Guide describes how to do this.

How does the app deduplicate users across environments?

I’ve run analysis on a collection run but the configuration was wrong. What can I do?

After my latest collection run, why do all license pools have zero allocated licenses?

How do I know which version of the app I am running?

From v1.1.0, a constant was introduced in both the Collector and the Reporting apps to display the app version. This has been updated in v2.0.0 to the following based on application name updates.

Collector App: LRDC_APPIAN_LICENSE_REPORTING_DATA_COLLECTOR_VERSION
Reporting App: ALR_APPIAN_LICENSE_REPORTING_VERSION

Information for v1.1.1 and older versions can be found below:

How should I configure reporting to see details per app but also grouped at business unit level?

From v1.1.0 onwards the Appian Usage Insights Quick Start Guide describes how to do this.

How do I configure flat app thresholds?

From v1.1.0 onwards you can do this via the related action within any license type record. See the Appian Usage Insights Quick Start Guide for more information.

Do you have examples or scenarios of how to set up the business entities?

Why do I have to upload collection data from all of my environments at once?

Can I use a non-production environment to host the reporting app?

How can I export the reports?

How do you report on non-prod and prod licenses separately, where users need to have one license per environment?

Install the reporting app once per environment tier - e.g. a Dev reporting component, one for Test, one for Prod etc. Load only Dev environment collections into the Dev reporting component and so on.

How do I configure the collector app to gather login information for the last year?

Tags: monitoring

Appian Usage Insights / Appian License Tracking FAQs

joel.larin — Tue, 10 Jun 2025 23:08:26 GMT

Revision 7 posted to Article by joel.larin on 6/10/2025 11:08:26 PM

Why does my application package include something called “Appian License Tracking”?

The application tracks license utilization and may, in future iterations, more closely track application usage based on log availability within Appian.

How do I install the apps?

The bundled Appian License Tracking Usage Insights Installation Guide describes how to do this.

How do I upgrade to the latest version of the apps?

The bundled Upgrade Notes document describes how to do this.

How should I use the apps?

The bundled Appian License Tracking Quick Start Guide describes how to do this.

How does the app deduplicate users across environments?

I’ve run analysis on a collection run but the configuration was wrong. What can I do?

After my latest collection run, why do all license pools have zero allocated licenses?

How do I know which version of the app I am running?

From v1.1.0, a constant was introduced in both the Collector and the Reporting apps to display the app version. This has been updated in v2.0.0 to the following based on application name updates.

Collector App: LRDC_APPIAN_LICENSE_REPORTING_DATA_COLLECTOR_VERSION
Reporting App: ALR_APPIAN_LICENSE_REPORTING_VERSION

Information for v1.1.1 and older versions can be found below:

How should I configure reporting to see details per app but also grouped at business unit level?

From v1.1.0 onwards the Appian Usage Insights Quick Start Guide describes how to do this.

How do I configure flat app thresholds?

From v1.1.0 onwards you can do this via the related action within any license type record. See the Appian Usage Insights Quick Start Guide for more information.

Do you have examples or scenarios of how to set up the business entities?

Why do I have to upload collection data from all of my environments at once?

Can I use a non-production environment to host the reporting app?

How can I export the reports?

How do you report on non-prod and prod licenses separately, where users need to have one license per environment?

Install the reporting app once per environment tier - e.g. a Dev reporting component, one for Test, one for Prod etc. Load only Dev environment collections into the Dev reporting component and so on.

How do I configure the collector app to gather login information for the last year?

Tags: monitoring

Appian Usage Insights FAQs

joel.larin — Tue, 10 Jun 2025 23:04:23 GMT

Revision 6 posted to Article by joel.larin on 6/10/2025 11:04:23 PM

Why does my application package include something called “Appian License Tracking”?

The application tracks license utilization and may, in future iterations, more closely track application usage based on log availability within Appian.

How do I install the apps?

The bundled Appian Usage Insights Installation Guide describes how to do this.

How do I upgrade to the latest version of the apps?

The bundled Upgrade Notes document describes how to do this.

How should I use the apps?

The bundled Appian Usage Insights Quick Start Guide describes how to do this.

How does the app deduplicate users across environments?

I’ve run analysis on a collection run but the configuration was wrong. What can I do?

After my latest collection run, why do all license pools have zero allocated licenses?

How do I know which version of the app I am running?

From v1.1.0, a constant was introduced in both the Collector and the Reporting apps to display the app version. If the constants LMA_R_APPIAN_USAGE_INSIGHTS_COLLECTOR_VERSION or LMA_R_APPIAN_USAGE_INSIGHTS_REPORTING_VERSION do not exist in your app, you are either running v1.0.0 or v1.0.1. In this case, if your reporting database includes the Stored Procedure LMA_SP_USERS_BY_license_TYPE, then you are running v1.0.1.

How should I configure reporting to see details per app but also grouped at business unit level?

From v1.1.0 onwards the Appian Usage Insights Quick Start Guide describes how to do this.

How do I configure flat app thresholds?

From v1.1.0 onwards you can do this via the related action within any license type record. See the Appian Usage Insights Quick Start Guide for more information.

Do you have examples or scenarios of how to set up the business entities?

Why do I have to upload collection data from all of my environments at once?

Can I use a non-production environment to host the reporting app?

How can I export the reports?

How do you report on non-prod and prod licenses separately, where users need to have one license per environment?

Install the reporting app once per environment tier - e.g. a Dev reporting component, one for Test, one for Prod etc. Load only Dev environment collections into the Dev reporting component and so on.

How do I configure the collector app to gather login information for the last year?

Tags: monitoring

Integrating using Web Services

joel.larin — Tue, 10 Jun 2025 17:41:52 GMT

Current Revision posted to Article by joel.larin on 6/10/2025 5:41:52 PM

Appian can use Web Services to integrate with external systems as a service provider (other systems calling Appian) or as a client (calling other systems from Appian). Most common protocols and standards are supported by default, but you can extend the platform using Appian's plug-in framework.

The recommended approach for Appian to access other systems is through use of the Integration Object.
The recommended approach for other systems to access Appian is through the Web API Object.

Calling Other Systems from Appian

Anytime Appian calls another system using supported authentication and methods, it should be configured using an Integration Object, paired with a Connected System. The Connected System object allows for multiple Integrations to be configured with one system, while hosting the authentication configuration in one place.

Querying vs. Modifying Data

Developers should always be aware of whether the integration will be querying (read-only) or modifying (read/write) data and select the appropriate checkbox for Usage when configuring an Integration object.
- Note: Appian will restrict developers from placing Integrations that modify data in places where duplicate calls can occur.
Unlike other Web Service smart services, Integration objects can be called in SAIL or in process.
Queries via an Integration object can also be used as the source for a service-backed record to create a structured, navigable interface for that data in Appian.

Working with JSON

When building the request body of an Integration object as JSON, you should create CDTs or use dictionary syntax that matches the expected structure to structure the data, and then use the function a!toJson to format the body. This will account for special characters and nulls, and always produce a well-formed structure.
When parsing the response body of an Integration that is expected to be JSON, you should use Automatic Output Parsing (“Convert the JSON Response body to an Appian value”). This will always return your result as structured data in Appian.
- Note: If there are any Date or Date and Time fields expected in the response body, you will need to manually convert these fields from a Text type (e.g. "2018-01-01T12:00:00Z") to a Date or Date and Time type by parsing the string.

Working with XML

When building the request body of an Integration object as XML, you should create CDTs or use dictionary syntax that matches the expected structure to structure the data, and then use the function fn!toxml to format the body. This will account for special characters and nulls, and always produce a well-formed structure.
When parsing the response body of an Integration that is expected to be XML, you should use the option to “Return the raw response body” and then use the function fn!torecord to convert the XML string into the structure of a matching CDT.
- Note: The namespace of the CDT must match the namespace of the XML. If you have the WSDL URL for the XML, you can automatically create CDTs which match the XML structure in your environment by adding it to the Call Web Service Smart Service, and then saving and publishing the process model.

Unsupported Methods or Authentication Configurations

For SOAP-based Web Services that use unsupported or non-standard data structures follow the advice in the Advanced SOAP Web Service Configuration guide.

For Web Services using unsupported authentication methods you may be able to utilize the Advanced Call Web Service or Send HTTP Request plug-ins. If these do not work for your use case you can always write custom function plug-ins to perform the call.

Calling Appian from Other Systems

Other systems can use Web Services to call an Appian Web API to expose Appian expressions such as query data, modify data, or start a process. See the Best Practices for configuring an Appian Web API guide for more information.

Tags: integrations, Architecture

Sizing Hardware for Appian

joel.larin — Mon, 30 Dec 2024 18:41:56 GMT

Current Revision posted to Article by joel.larin on 12/30/2024 6:41:56 PM

Appian's hardware sizing process provides a general estimate of the hardware needed to run your Appian solution.

This estimate is based on several high-level business parameters and is typically used prior to the start of a project. The sizing can be repeated if parameters change significantly due to new business requirements.

The sizing recommendations apply to Production environments only. For non-prod environments we recommend following System Requirements for your Appian version.

NOTE: Hardware sizing is not a replacement for proper performance and load testing.

Requesting a Hardware Sizing

Fill out the Appian CS Hardware Sizing Survey to provide high level estimates of:
- Expected user load
- Process volume
- Data and document size
- Environment configuration
- Service level expectations
Email your Account Executive the completed sizing survey.
Your Account Executive will follow up with you to validate the inputs and provide you with guidance.

Tags: environments, Platform

Sizing Hardware for Appian

joel.larin — Mon, 30 Dec 2024 18:40:53 GMT

Revision 6 posted to Article by joel.larin on 12/30/2024 6:40:53 PM

Appian's hardware sizing process provides a general estimate of the hardware needed to run your Appian solution.

The sizing recommendations apply to Production environments only. For non-prod environments we recommend following System Requirements for your Appian version.

NOTE: Hardware sizing is not a replacement for proper performance and load testing.

Requesting a Hardware Sizing

Fill out the community.appian.com/.../Appian-CS-Hardware-Sizing-Survey-_2800_1_2900_.docx to provide high level estimates of:
- Expected user load
- Process volume
- Data and document size
- Environment configuration
- Service level expectations
Email your Account Executive the completed sizing survey.
Your Account Executive will follow up with you to validate the inputs and provide you with guidance.

Tags: environments, Platform

Sizing Hardware for Appian

joel.larin — Mon, 30 Dec 2024 18:40:28 GMT

Revision 5 posted to Article by joel.larin on 12/30/2024 6:40:28 PM

Appian's hardware sizing process provides a general estimate of the hardware needed to run your Appian solution.

The sizing recommendations apply to Production environments only. For non-prod environments we recommend following System Requirements for your Appian version.

NOTE: Hardware sizing is not a replacement for proper performance and load testing.

Requesting a Hardware Sizing

Fill out the community.appian.com/.../Appian-CS-Hardware-Sizing-Survey-_2800_1_2900_.docx to provide high level estimates of:
- Expected user load
- Process volume
- Data and document size
- Environment configuration
- Service level expectations
Email your Account Executive the completed sizing survey.
Your Account Executive will follow up with you to validate the inputs and provide you with guidance.

Tags: environments, Platform

Performance and Load Testing

joel.larin — Mon, 30 Dec 2024 18:34:47 GMT

Current Revision posted to Article by joel.larin on 12/30/2024 6:34:47 PM

Why Performance Test?

Performance testing can be used to answer critical questions about the application, such as:

Will pages load fast enough to satisfy end users?
Can the application store all of the data that will be collected?
Will performance be consistent over time?
Which areas of my application should I improve?

Answering these types of questions reduces risk, informs current business decisions and assists future planning. Performance testing is needed to determine if the application will perform within specification given a particular situation. It also validates if the resources provided to the application are sufficient for the given volume and data load. The "right" amount of performance testing can only be determined by the project sponsor and stakeholders after considering the importance or visibility of the application, potential revenue loss due to poor performance, and other risk factors.Appian designers should ensure that end user interfaces perform within the specification before they promote the feature to higher environments. If interfaces do not perform adequately during unit testing, they will not improve during performance testing. There are several ways that interface performance can be captured and various troubleshooting techniques. Please see Interface Performance and Debugging for more details.

Process Performance Baseline

When designing process models, designers need to pay attention to the response times between user tasks to ensure appropriate user experience. Similarly to interfaces, processes need to perform appropriately during unit tests, before they can be accepted for performance testing. Performance of individual activities is recorded in logs, and designers can utilize the Appian Health Check to find out if there were any expressions or smart services that could impact end users’ experience. Health Check also provides an HTTP Response Time chart that provides an aggregate view of performance within the environment. These tools should be utilized after every round of functional testing to monitor emerging performance risks. Absence of Health Check should not be a blocker to analyze performance test results. You can still analyze Appian Logs in their tool of choice (Splunk, SolarWinds, Grafana, New Relic, Excel). Additionally, designers can use network monitoring tools built into their browser, to record the exact performance of requests between user clicks during their unit testing.

Performance Testing

Performance testing should be done once the application is in a stable build with the majority of the functionality built out. The app does not have to be complete to get started, but needs to pass the QA/QC cycle, so that performance results are not skewed by application errors. Additionally, performance testing needs to be executed for major releases of the application. Over time, the test will grow to include additional applications and functionality as your platform use evolves.

There are two load factors to consider during performance testing:

Data Load - how much data is in the system during performance testing? This is a frequently overlooked factor but applications need to be tested with a pre-loaded set of data in order to ascertain how it will perform in a realistic situation. Performance testing is often executed with blank databases, which will not be the case 3, 6, 12 months or even at application go-live. Results from such testing will be inaccurate. Please read the Database Volume Testing play for tips on how to load data into your environment.
Load Volume - how many users are in the system creating transactions? When designing your test, you need to find out how many business processes are executed in a given timeframe by how many users. You also need to make sure that all other significant activity in the system is tested, to set up a realistic transaction volume scenario. Tests need to be designed to emulate real user activity, with appropriate pauses between interactions.

More details on methodology, complete with test design templates and helpful tips, can be found under Performance Testing Methodology.

Performance testing should have its own project plan and it should be considered its own agile project. A backlog of performance improvement fixes will start to build with each nightly performance test run. The business should prioritize the improvements based on impact and severity. Promote performance fixes on a nightly basis and rerun the performance test to determine the impact of each change.

Tools

You can execute performance tests using the Appian Locust tool, which uses the open source Locust load testing framework. It provides an easy, programmatic way to develop and execute load and performance tests for Appian. Alternatively, you can use standard web application performance testing tools. These include JMeter and LoadRunner.

Tags: Delivery, testing, Platform

Performance and Load Testing

joel.larin — Mon, 30 Dec 2024 18:34:20 GMT

Revision 8 posted to Article by joel.larin on 12/30/2024 6:34:20 PM

Why Performance Test?

Performance testing can be used to answer critical questions about the application, such as:

Will pages load fast enough to satisfy end users?
Can the application store all of the data that will be collected?
Will performance be consistent over time?
Which areas of my application should I improve?

Process Performance Baseline

Performance Testing

There are two load factors to consider during performance testing:

Data Load - how much data is in the system during performance testing? This is a frequently overlooked factor but applications need to be tested with a pre-loaded set of data in order to ascertain how it will perform in a realistic situation. Performance testing is often executed with blank databases, which will not be the case 3, 6, 12 months or even at application go-live. Results from such testing will be inaccurate. Please read the Database Volume Testing play for tips on how to load data into your environment.
Load Volume - how many users are in the system creating transactions? When designing your test, you need to find out how many business processes are executed in a given timeframe by how many users. You also need to make sure that all other significant activity in the system is tested, to set up a realistic transaction volume scenario. Tests need to be designed to emulate real user activity, with appropriate pauses between interactions.

More details on methodology, complete with test design templates and helpful tips, can be found under Performance Testing Methodology.

Tools

Tags: Delivery, testing, Platform

Manage Your Appian Cloud Upgrade

joel.larin — Thu, 21 Nov 2024 15:06:01 GMT

Current Revision posted to Article by joel.larin on 11/21/2024 3:06:01 PM

Appian releases a new version of its platform quarterly. Each release brings valuable new features for both end users and designers. They also provide resolutions to prior issues and enhance security. Converting your Appian Cloud instances to the latest release is a fully automated process, and comes at no additional cost. If you run a self-managed installation of Appian, refer to this Upgrade Guide for help on updating your platform.

Typically, our Support team will suggest an upgrade to the latest version within 30 days of its release. We recommend keeping your environment versions up-to-date, ideally within two releases of the current one. If your platform engages multiple Appian teams, it would be beneficial to have an Appian Center of Excellence leading the process.

Performing version upgrades is an essential part of platform maintenance and can usually be scheduled just two weeks after a release is made generally available. Not performing these upgrades can mean expiration of Support Services for your installation. During the upgrade process, Appian will make every effort to minimize service interruptions by performing maintenance activities outside of regular business hours.

1. Make a plan

Every new version of Appian is backwards compatible, so your applications should run as usual post-upgrade. If however you choose to leverage a new feature, or there are significant UI changes as part of the upgrade, it’s possible your users will be affected by the change. Therefore, it's important to make a plan and communicate changes effectively throughout the upgrade process. Some important steps in the planning process include:

Review Appian Release Notes
Identify and alert stakeholders of any significant changes
Make plan to test and deploy upgrades

Before initiating your cloud upgrade, take some time to review the Release Notes and Product Webinar for the latest Appian release. This will help you identify new features your developers can utilize and create a list of deprecations that may require revisiting. Ensure that you're reading the latest set of release notes, or the version applicable to your upgrade, by selecting the version drop-down menu and selecting the latest Appian version.

As you review the Release Notes, keep an eye out for any UX changes, as you may need to notify users of these improvements and how it affects the application experience.

Once an impact assessment of the upgrade has been made, identify all stakeholders, including end users, developers, and support staff. Notify these stakeholders about specific changes either through a site banner or via an email detailing the upgrade. Good communication is fundamental to a successful upgrade.

Lastly, you should draft an upgrade deployment plan before initiating the upgrade process. This plan should take the following into consideration:

Upgrade Timeline

You may plan to upgrade your test environment on Monday, while scheduling your Dev and Production environments for Friday of the same week. Your upgrade cadence can be discussed with Support when scheduling your upgrades. The takeaway here is having adequate time to validate the test environment before upgrading Dev and Production. This is important to note since you can’t deploy code from higher to lower versions of Appian (23.2 to 23.1), and as such deployments will be paused during upgrades.

Test Case Identification

Before you upgrade your environments, you should determine test cases and validation procedures for each environment. This might include things such as:

Smoke testing
Regression testing
Automated testing

See the Appian Testing Guide for a comprehensive overview of testing in Appian.

2. Schedule your upgrade

Authorized technical support contacts will receive an email notifying them about the exact date, time, and duration of the maintenance window to upgrade their site(s). If the proposed upgrade schedule doesn’t fit your needs, or you want to do a staged rollout for your environments (recommended), you’ll need to update the upgrade schedule directly from the Cloud Installation site provided in the upgrade email.

You can also coordinate with the Appian support team by opening a support case on Forum. The support team will help you establish an upgrade sequence, and talk through any unusual circumstances or considerations for your upgrade.

Every environment that is hosted on the Appian cloud will need to be scheduled for an upgrade. The Test environment is often upgraded first to limit the number of interruptions in Development and Production. This also allows for the possibility of rolling back and aborting the update if needed. The Development and Production environment upgrades will be scheduled shortly after the Test upgrade, with some time allotted for testing in between.

Communicate with support if any changes are necessary to the schedule, and be sure to fully validate your test environment before upgrading the Development and Production environments. Keep in mind that there will be a pause on deployments while updates are being made to a given environment.

3. Perform a trial run

Once the cloud upgrade is completed in your testing environment, revisit your upgrade deployment plan to perform the necessary tests. Smoke testing is a good way to quickly check for any major issues, while regression testing allows you to examine the upgrade in greater depth. See our Appian Testing Guide for a complete overview of testing in Appian.

To reduce the amount of manual effort involved in testing, Appian also has Automated Testing you can employ throughout the application development lifecycle. We recommend implementing automated testing early in your projects, as it will greatly reduce upgrade testing costs and allow for a faster, smoother update process.

Be aware that updates to your automated tests may be needed if UX changes have occurred in the new Appian version. Changes that affect your plug-ins and integrations should also be noted. The Deprecations and Removals sections of the Appian Release Notes are a great place to start testing for such changes.

4. Complete your upgrade

Once you've fully validated the upgrade in your Test environment, you should upgrade Production, followed by Development. Ending with the Development environment gives you the option of handling last minute hotfixes and avoids blocking your development efforts. Smoke testing should be again be performed in Production and Development to test for critical application functionality.

In the unlikely event that you experience something unexpected after the upgrade, contact Appian Technical Support for assistance. Support will usually be able to provide a work around, or help plan an application hotfix to resolve the issue. If the issue can’t be resolved in this manner, you'll also be able to restore to the latest backup pre-upgrade. All of these options should be discussed with Appian Technical Support to ensure any issues are addressed appropriately.

Be prepared to support your developers and end users post-upgrade, particularly if there have been UX or integrations related changes. If changes are significant enough, be sure to revise your supporting documentation and training materials.

Tags: environments, Configuration Management, Platform

Manage Your Appian Cloud Upgrade

joel.larin — Thu, 21 Nov 2024 14:40:28 GMT

Revision 85 posted to Article by joel.larin on 11/21/2024 2:40:28 PM

1. Make a plan

Review Appian Release Notes
Identify and alert stakeholders of any significant changes
Make plan to test and deploy upgrades

As you review the Release Notes, keep an eye out for any UX changes, as you may need to notify users of these improvements and how it affects the application experience.

Lastly, you should draft an upgrade deployment plan before initiating the upgrade process. This plan should take the following into consideration:

Upgrade Timeline

Test Case Identification

Before you upgrade your environments, you should determine test cases and validation procedures for each environment. This might include things such as:

Smoke testing
Regression testing
Automated testing

See the Appian Testing Guide for a comprehensive overview of testing in Appian.

2. Schedule your upgrade

3. Perform a trial run

4. Complete your upgrade

Tags: environments, Configuration Management, Platform

Shared Object Management Overview

Appian Max Team — Thu, 19 Sep 2024 17:46:39 GMT

Revision 6 posted to Article by Appian Max Team on 9/19/2024 5:46:39 PM

Overview

Description of the purpose and scope
Owner or owning group
Implementation usage instructions
Who to notify when updates are made

Object Types

Object type	Criteria	Example
Expressions Decisions	Logic containing reusable functionality	Email address validation Mailing address formatting Display name formatting
Data Types Data Stores Query Rules Constants	Reference data across applications	List of States/Countries User details
Interfaces	Common interface sections	Mailing address input form User details input form
Web APIs	Reference data exposed externally	User details
Records	Records referenced by or containing data from multiple applications or synced records representing reference data	Study Engagement
Process Models	Logic containing reusable functionality	User synchronization
Connected Systems Integrations	Reusable connections to external systems	Transfer documents

Identification and Cataloging

The identification of common objects is the responsibility of the application development team and the Center of Excellence (CoE). Some heuristics for identifying common objects could include:

Is the functionality going to be accessed by all platform users?
Are other applications going to leverage the same functionality? e.g. vendor search?
Is the functionality agnostic of the application it is in? e.g. a list of countries
What is the potential scope of a common object; eg. Department, Region, Global

These questions can be asked before, during and after the development cycle, but the sooner common functionality is identified the easier it is to classify it and leverage it across the platform.

Security and Ownership

Common Object Use and Maintenance

Example Process

Steps to Modify Common Objects

When an object is modified in a common app, follow the below steps:

Request to make a change from the object owner(s).
Before making the change, check for dependencies on the object to see which teams could be impacted by the rule modification. Reach out to the associated owners to ensure the change is compatible before proceeding.
The owner grants edit access to the application(s).
If a common object needs to be modified that already has changes in progress, check to see if the change has already been deployed throughout the environments. More complex objects, like records, have a higher likelihood of a change in progress. If that is the case, reach out to the developer associated with the object and ensure the proposed changes are compatible before proceeding. Other measures may have to be taken, e.g. feature toggles, to get the changes deployed without breaking precedents.
Owner revokes edit access to the application(s).

Tags: Delivery, Architecture

Managing Multiple Concurrent Delivery Teams

Appian Max Team — Thu, 05 Sep 2024 18:45:03 GMT

Current Revision posted to Article by Appian Max Team on 9/5/2024 6:45:03 PM

Your Appian project team will likely consist of multiple designers and your program may have multiple independent project teams. Concurrent delivery would be trivial if everyone worked on completely isolated changes. However, strong Appian programs take advantage of reusability, like Records, that should be shared broadly across the platform. You'll also likely want to reuse common objects (like utility rules) across multiple applications. Changes to database schemas and external systems also need to be managed.

Unlike custom code development, Appian does not use branching/merging. Whether designers are working in a shared development environment or in different development environments, you'll need to coordinate between them to avoid the common pitfalls of concurrent delivery:

Overwriting another designer's changes to an object.
Changing common components without warning.
Deploying partially complete work for a different application/release.

For all concurrent delivery scenarios, maintain comprehensive test coverage, including regression testing, to validate all existing and new features. Automated test coverage will significantly reduce effort and risk.

Single Application Release

You have one team working in a shared development environment on one application and one release schedule at a time.

Be mindful in how you plan your sprint, in case dependencies exist between stories. If common rules are needed to support multiple stories, ensure those are worked on first to remove impediments.
Be mindful of the Object Overwrite Prevention notifications, and do not override anyone’s lock on an object without proper coordination. If you do happen to get overwritten, you will get a notification that the object version is out of date and you will want to merge your changes accordingly.
Minimize conflicts by splitting rules into sub-rules, process models into sub-processes, etc. These objects can be modified independently.
Restrict deployment duties to a smaller group.
- Team members without deployment responsibilities should never make changes to higher environments.
Minimize common deployment errors by ensuring all deployment packages are reviewed by multiple people.

Overlapping Releases of the Same Application

You have one team wrapping up work on the next release and a second team getting started on a future release.

Appian recommends against this because the amount of overlapping changes is usually very high. Projects that follow an agile approach and release frequently should not need concurrent delivery efforts.
Special Case: To make an urgent fix to production while development on the next release is in progress follow the instructions to deploy an application hotfix.

Multiple Independent Applications

You have different teams working on releases for different applications at the same time. There may be objects shared between applications and the releases may be deployed at different times.

Use the general guidance provided above for working with a single application release. Coordination will need to be more formal between teams than coordination within a single team.
- A more robust object tracker that categorizes modified objects by application can be used to manage changes and aid in patch deployment in this scenario.
Isolate objectsusing applications.
- Assign a clear owner for every application (including shared applications).
- Coordinate with the owner to request changes to that application.
- Use a different naming prefix and folder hierarchy for objects in each application to quickly indicate ownership.
- Restrict editor/admin access to avoid accidental changes.
- Create documentation to manage dependencies between applications.
Utilize a Staging Environment to test deployments and catch dependency issues before they reach Production
For shared object applications, leverage packages for deployments.
- Leveraging packages minimizes the risk of half-baked code being pushed to the higher environment by development teams using shared objects. For example, if Team A is ready to deploy Shared Object A, but Team B is making changes to Shared Object B, deploying the full Shared Object Application will result in unfinished code being promoted to the higher environment. Instead, if Team A is only using Shared Object A, they should push only that object.
For objects shared between applications (like Records), deploy partial changes but hide them from end-users until they are ready.
- Shared objects should be included in a shared application which has a clearly defined owner.
- Use highly-restrictive object security role maps to hide new record types, reports, actions, and news events.
- Use feature toggles to defer new rule or process model behaviors, or to hide changes to existing objects and interfaces.
  - A feature toggle can be created with a boolean constant/rule that's used at key points in the application to enable a new feature.
  - For example: Two independent releases both need to add a view to a record type. Add them both and deploy, but design a feature toggle in the visibility expression to hide them from end-users until each application is formally released.
Deploy updates frequently to a Test environment.
- As work is completed and objects reach a stable state, they should be frequently deployed to a test environment and peer reviewed.
- For very large, complex teams, daily deployments can be useful for successful regression.
Apply governance.
- Hold teams to similar best practices, schedules, and guidelines for development and deployments.
- Hold recurring “Scrum of Scrums” meetings to keep teams on the same page.
- Align regularly on sprint schedules, upgrade schedules, and any other activities that may interfere with regular deployments.
- Ensure security is properly configured on shared objects, and establish a process for allowing updates. This can be an access request / approvals process, creating a core team that manages shared object updates, assigning special access for shared objects to only team leads from the individual teams, etc.

Appian recommends using a shared development environment. This approach:

Has lower infrastructure cost and complexity.
Avoids the need to merge objects from different environments.

If you are forced to use separate development environments (for contractual reasons or otherwise), there are different considerations:

Although objects can be modified in parallel on different environments, you still need to minimize the amount of overlap to make merging easier.
- For example: Performing hotfixes in a separate environment is recommended because the amount of overlap is typically very small.
Coordinate and plan merge activities as part of a program-wide release schedule.
Avoid creating objects with the same name or purpose in different environments.
- Use unique naming prefixes or coordinate shared object creation between teams.
Merge to a consolidated test environment as frequently as possible to minimize risk.
Use Compare and Deploy to to identify conflicts between object versions.

Tags: Delivery