Quick Apps Lifecycle Considerations

Overview

Quick Apps are extremely fast and easy to build and deploy. There are, however, some considerations to ensure that Quick Apps do not interfere with deployment or maintenance of any traditional applications on the same environment.

In addition, this page provides guidance for customers who wish to enhance their Quick Apps with additional functionality, or maintain additional governance and oversight over which apps are created.

Lifecycle patterns

The primary lifecycle pattern of a Quick App is similar to the lifecycle of a regular Appian app. Customers will deploy the Quick App in a development or test environment and make modifications, either in the Quick Apps Designer or in Appian Designer. Remember that since lookup options for any single-select or multi-select fields are stored in the database, you'll need to export them separately to insert the target environment.

	Design in Non-Production Environments
First version	Design in Development
First deployment	Deployed from Development to Production like other Appian apps.*
Subsequent development	Modify using Appian Designer in your Development environment. After the first deployment, the app cannot be modified using the Quick Apps Designer.*
Each subsequent deployment	Same as first deployment.*

• This item requires IT involvement in addition to the business users designing the Quick App. See the checklist below to ensure that your IT users are correctly provisioned for these activities.

In this pattern, Quick Apps are created and updated in your Development environment. You can give business users access to this environment as Quick App Creators without them having access to your traditional application development. Quick Apps can be built and iterated on as needed here - while the underlying object names and identifiers can change on each update of the app, the system ensures that they won't collide with any other objects in the same environment.

When the functionality is stable, the app can be promoted to higher environments including Production, through your traditional deployment process. Remember that as per the note above, once the app is exported and promoted for the first time, no further updates to that app should be made in the Quick Apps Designer on your development environment. After that point, any further enhancements or changes will need to be made through Appian Designer, just as with traditional apps.

This pattern allows more easily for oversight and governance of which Quick Apps are created. In addition, it makes it easy to enhance a Quick App's functionality through Appian Designer in the Development environment before promoting it to Production, if that is desired. Finally, it has the benefit of following the same flow as development of traditional apps, which may fit more easily into your existing processes. The downside is that the benefits of Quick Apps can only apply to the first version of each app with this process. After the initial deployment, application developers will be required to make any further update to the app, which will make enhancements to them dependent on the same resources who develop your traditional apps.

Design in Production

Making and updating your Quick Apps directly in your production environment is also possible. After each update, export the app from Appian Designer and import it to each of your lower environments. Because updating the app in the Quick Apps Designer does change object identifiers, be sure to delete the app in lower environments before backloading the application there. Otherwise, you will encounter import errors when attempting to backload the application. Your IT team should audit the Quick Apps Designer regularly to check for recently updated Quick Apps - Appian recommends performing this once at the beginning of each of sprint / development cycle, once in the middle, and once in the last few days of the cycle.

This ensures that each environment in your stack has a copy of the same functionality, as you would get in a traditional SDLC where applications are promoted from lower environments, while preserving your business users' ability to generate Quick Apps in Production. It also ensures that objects which are promoted from a lower environment will never have name collisions with the auto-generated Quick Apps objects, that are only discovered on deploying to Production.

You may notice a performance impact on your Production system during the short window (approx. 45-75 sec) that is required to create or update a Quick App. See the first question in the FAQ below.

Quick Apps readiness checklist

The following steps are a general guide you can use to prepare for allowing users to create Quick Apps in your system.

1. [Optional] Create new data source

While Quick Apps interact fairly little with any of your existing applications, creating a Quick App does make schema modifications to create new tables. A separate data source used only for Quick Apps can offer the security of only allowing business users to make schema changes in a data source that does not house any business-critical applications.

2. Provision IT users

To move apps between environments, you will need users who are Designers in both Development and Production environments, so that they can access Appian Designer for exports and imports. For this, you can use existing protocols for deployments, as these deployments are no different from traditional application deployment. These users will also need to be Quick App Creators on the environment where Quick Apps are being created, so that they can identify which Quick Apps have been created or changed recently.

3. Establish a Quick Apps access plan

Ideally, your IT users mentioned above will also be system administrators on the environment where Quick Apps are created, so that they have a guarantee of being able to see all Quick Apps. If they cannot be, you should establish a process where all Quick App Creators add your designated IT users as owners of any new Quick Apps that they create (if they forget to do it on creation, the app can always be updated to add new owners). Without this, the app may not be accessible to the IT users who will move it between environments.

4. Provison Quick App Creators

If you're allowing Quick Apps to be created in your Production environment, then limit Quick App Creators to known parties who should have the ability to push out Quick Apps to their teams or departments directly in Production. If you're only enabling Quick App creation on lower environments and have existing controls for deployments to production, you can safely expand Quick Apps Creators and follow existing protocols for deployments. Remember that the only additional access that Quick App Creators receive is to the Quick Apps Designers. While they can create Quick Apps that are accessible by any users in the system that they choose, they cannot access Appian Designer or otherwise directly modify arbitrary design objects or system settings.

FAQ

How much will each new Quick App disrupt or slow existing apps on my Production environment?

Creating or updating a Quick App is an intensive operation, similar to importing a normal application. While the impact will vary depending on current system load and hardware, you can expect some slowdown during the period while the Quick App is being created or updated (approx. 45-75 seconds).

Each Quick App is a standalone application. It does not interact with existing database tables and only reads from a few existing design objects. This makes it impossible for a Quick App to alter any existing functionality on an environment. While it will be incapable of breaking the functionality of any other app, it can slow performance as much as any lightweight traditional application.

Details:

• Each Quick App generates a new set of design objects and database tables. The new tables at most contain identifiers pointing to some existing tables, but are never pointed to by database tables of existing applications.
• A Quick App can reference existing groups if they are added as users of that Quick App
• A Quick App can reference existing record types if they are added as fields of that Quick App
• Updating a Quick App recreates and deploys a new version of it, deleting the previous set of objects. This adds a similar amount of load as deploying a new version of an existing traditional app.

Suggestions:

• If you're concerned about database performance or having business users making schema changes, making a separate data source that is only used by Quick Apps will ensure that they do not compete with RDBMS reads and writes for your existing applications. It also isolates any schema changes by business users in a different location from any mission-critical apps.

How can I validate Quick App functionality before deploying it to my Production environment?

The interfaces you configure when creating a Quick App can be previewed to make sure the design is correct. The system performs extensive validations to guarantee that the generated functionality will be bug-free. If anything is wrong, Quick Apps are extremely easy to update or delete.

Details:

• Any error on creating or updating a Quick App is immediately rolled back; the operation always either succeeds completely, or does nothing (and tells the user).
• Deleting a Quick App removes everything associated with it (design objects, runtime objects, database tables) to literally make the state of the system as if the Quick App had never been created. This makes it easy to remove Quick Apps with poor design. Note, however, that if a Quick App has been modified in Appian Designer, it can only be deleted from the Quick Apps Designer by a system administrator.
• Updating a Quick App does not lose the data associated with it, so changes can be made in the same environment even after the Quick App is in use.
• In short, we provide extensive guarantees around the feature that are specifically designed to make it safe to use in a Production environment.

Suggestions:

• If these guarantees are not sufficient, a new Quick App can be created in a staging or development environment to prove out its design before creating it in Production, or promoting it from a lower environment to Production via the same means as a normal application. This is the second pattern suggested above.

How can I govern or audit Quick Apps so that new functionality isn't pushed to everyone on my Production environment without approval?

Quick Apps are only visible to the users they are configured for. All Quick App Creators can immediately publish new apps, so the Quick App Creators role should be restricted to users who will have the authority to publish new content to Tempo.

Details:

• All Quick Apps Creators can make new Quick Apps and update any existing Quick App
• Quick Apps can be deleted by the user who created them, as well as any Quick App Creator who is also a system administrator.
• Quick Apps can be converted to a standard application by the user who created them, as well as any Quick App Creator who is also a system administrator. The former Quick App will be removed from the Quick Apps Designer and made accessible only as an application in Appian Designer, without changing any of its functionality or data.
• Quick Apps are only visible by the users configured to use that Quick App, so they do not affect or surprise other users. If a Quick App is published to too broad of an audience, it takes approximately a minute to change the users to a smaller list. Like every update to a Quick App, this will smoothly change access without inhibiting any existing functionality.

Suggestions:

• To open up Quick App design to a larger pool of users, give them access to your development environment as Quick App Creators. They will not have access to application design in Appian Designer, and so will only have the ability to prototype Quick Apps. These Quick Apps can then be vetted and deployed through traditional processes.

Feedback