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.
The most important single note is that it is important to stop updating a Quick App using the Quick Apps Designer as soon as it has been exported from the current system. Updating in the Quick Apps Designer changes some of the identifiers in application objects, as they are regenerated during the update. This means that the app can not be predictably merged with other versions of itself using Appian's import / export functionality.
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.*|
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.
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.
The following steps are a general guide you can use to prepare for allowing users to create Quick Apps in your system.
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.
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.
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.
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.
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.
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.
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.
Quick Apps Lifecycle Considerations