Publish

Overview

Publishing changes refers to the process of applying and making visible any updates made to your app configuration in App Studio. These updates can include edits to Layout, Expressions, Workflow, Security... anything that can be edited on the App in App Studio. 

Changes will be saved without affecting the live version so a number of changes are stored up to release in one go once you are ready to. They must be explicitly published to become active and visible to users.

Publishing will mean that end-users receive the most current version of your application with the changes you have made. When a User has their workspace active, the App periodically polls for a new version in the workspace and will sync the new App definition for Users so they do not need to do anything in order to see the latest App version.

To give some context we will look at Publishing updates to an Innovation Health Check App which needs to be updated following an internal process review meaning the checks in the audit have changed.

How to Publish An App

Publlishing an App will release all of the pending updates that have been made in App Studio for the App. Take note that if multiple App Builders have made changes then all changes made by all App Builders will be released at the same time.

Method 1: Via the Publish Section

1. Navigate to the Publish folder in the left-pane menu.

2. At the bottom of the screen, click Publish Version to open the Publish modal.

3. Optionally add Publish Notes and whether to take a version Snapshot.
4. Click Ok to publish and release the latest App Changes

Using our scenario for updating the Innovation Health Check audit App, we have already changed the Audit Questions and are now ready to Publish, we navigate to the Publish section and click on Publish Version at the bottom of the screen.

We have added a release note to explain what changes we have made. Whilst this is an optional feature, we highly recommend that for good App governance that you use this feature. We'll explain later tin this article about how they play their part in version control but they are also very effective in issue diagnosis and letting other App Builders and yourself reference back to what changes were made and when.

The Snapshot feature will also be explained in more detail later in this article but anytime there are more major version releases of an App, taking a Snapshot will allow rollback of the configuration should there be any issues that arise in testing the latest published version.

All that is left is to click okay and our updated App will be rolled out to Users.

Method 2: From Any Screen in App Studio for the App

1. Look to the top-right corner of any page.

2. If a banner stating there are unpublished changes and a green Publish button is visible, click it to initiate publishing.

When Is an App Ready to Publish?

From a Governance perspective an App is ready to Publish when you are happy with the changes that have been made and are ready for your Users to receive the new version. For larger changes this may come with a release process to inform the Users what has changed but for minor changes an agile development approach should mean that a lot of changes can be made without the need for extensive release notes to all end users.

However, there are also a minimum set of requirements that must be met for an App to be publishable. The status of these are given in the App Build Checklist. To view the current readiness of the App:

1. Navigate to the Publish folder in App Studio
2. Open the App Build Checklist section at the top of the folder

In order to Publish the App, there cannot be any of the checklist items that are Red (Amber is okay but not advisable). If you try to Publish the App without completing all of the Checklist items then an error will appear stating the reason the App could not be Published.

When Checklist items are Red, the item is click through to allow you to fix these issues efficiently. In our example above, we cannot Publish our Innovation Health Check App as there is no Icon set so we would click on the 'Is Icon Set?' text and set an icon before attempting to Publish again.

App Build Checklist Items

• Is Icon Set? An Icon is required so that it can display in the LaunchPad and App Title
• Is Description Set? The Description is a high level overview of what the App is for. Without this Users could be confused as to it's purpose.
• Is Report Set? (Requires Default) Reports are a critical component of Apps as they are what the User is presented with when they select the App in the LaunchPad and bridge the navigation to Records as well. A default is needed to give the primary navigation when selecting the App.
• Is Report Filters config valid? Report filters are a standard feature of all Reports and so at least one filter field is required.
• Are too many Sortable Fields set? Large Apps with too many Sortable Fields reduces performances as too many indexes are needed on the data so this is capped for each App.
• Is Form set (With Templates & Fields)? Similarly to Reports, having a Form with a Field showing in a Template is the defined minimum for any functional App in Softools.
• Is Title Field Set (Optional) Not having this component will not prevent a Publish but it is advised to have a unique reference to each Record via a named Field.

Versioning, Publish History & Rollback

Versioning

When accessing the Publish section, the Published Version area will display the Current Version, the Version to be Published and the Status of the last Publish attempt:

Current Version Box (Left):

• Current version number
• Name of the last publisher
• Date and time of last publish

Latest Version Box (Right):

• Next version number (to be assigned upon publish)

Status Report (Bottom Table)

• Status - If it is not successful then a error message will appear by the language being published. Contact Softools Support if you cannot understand the error message.
• Language - Each supported language has it's own version of the latest App configuration published.
• Elapsed - Time taken to release the version.
• Notes - Optional release notes are available as a hover over.

Publication History

A Published Version section is available, displaying:

• A chronological list of all published versions with success status

• The user who published each version

• Timestamp of publication

• Associated release notes (if provided)

This feature enhances collaboration and auditability, especially useful for teams managing critical health applications like the Innovation Health App.

In our Innovation Health Check App we can see that we have multiple App Builders making contributions. It is therefore very useful to be able to hover over the Notes column and see what changes have been made by the different App Builders. Having multiple App Builders working on an App does lead to needing a strong governance process, particularly if they are likely to be working at the same time as all App Builders combined changes are Published on a release.

Rollback

When making a Release there is the Take Snapshot toggle. This will mark the Version that is released as available in the Rollback Snapshots. If you forget to take a Snapshot then there is also the ability to add a Snapshot from any Publish that has been made in the last 90 days.

Click on Add Snapshot at the bottom of the Rollback Snapshots table to open a modal where you can select the version and click Ok to confirm and add the release as a snapshotted version.

This then means that you can rollback to a snapshotted App version. This will roll back the App Configuration only. It does not mean the record data will roll back with it so if that is needed then ensure you take a full .csv export before making large changes in case of a need to reference back and restore.

• At the bottom of the screen, click Rollback to open the rollback modal.

• Select the Version that you would like to rollback to.
• Click Ok to publish and release the latest the snapshot as the latest version.

Note: This is an example of how adding Publish Notes can be crucial in some scenarios including rollback to find the correct prior App version. 

The Publish folder will then show that the App has been successfully rolled back.