Brief Overview

One of WalkMe Mobile's largest value-adding components is the ability for customers to push new content to their apps independently of the app's release cycle.

The SDK's widespread influence within the app means attention and planning are required when testing campaigns before publishing to production and when making changes to content already live in production.

How to Manage Production Updates with a QA app Instance

For apps that have a QA or staging copy available to content builders, the recommended flow is to first create new content and make any updates to existing content on the QA instance.

Since the QA instance is only available internally, content can be freely published without any concerns of affecting end users.

After content is validated, it can be duplicated to the production app instance and published to end users.

How to Manage Production Updates in a Single App Instance

Validating unpublished campaigns

Campaigns are not accessible to the end users until they have been published to production (a best practice is to always publish campaigns that are currently available to end users, even if they are not supposed to be auto-played).

To test campaigns before they are published for the first time, use Simulate Mode. When simulating an unpublished campaign, it behaves as if it's published, which allows testing before publishing.

Alternatively, it's possible to use any of these methods to segment a campaign so that it's only available to a limited group of users (such as a QA team):

• Set a User Attribute that will identify the user group, and use that User Attribute in a segment (for example: set a boolean attribute named "is_qa" that will return the value "true" for the QA team).
• Use the End User Identifier to identify users, and use a User IDs List to only mark the end users who are part of the QA team.
• If there's a distinctive app version that only the QA team has access to, the campaign segment can be set to only target users on that app version.

Once the campaign content has been validated, the portion of the segment that limits its access should be removed so it can become available to all users.

Managing updates to published campaigns

Once a campaign is published, every change saved to it will automatically be deployed to end users.

When making production updates, it is important to understand the nature of the update:

• If an update is very small, it may be acceptable to save such a change to a published campaign without iterating it through a testing process. For example: adding a comma to a campaign's text, or adding an X button to a ShoutOut.
• If an update is viewed as important or major enough to require testing, the change cannot be made directly on the published campaign. In that case, the campaign can be unpublished to allow changes without the changes immediately affecting production, or it can be duplicated so that all changes are made on an unpublished copy that can later replace the original.

Whether the changes are made to the original campaign after it is unpublished, or if the changes are made to an unpublished duplicate, the changes validation process is the same as described above for unpublished campaigns.

Production update process summary