# Moving Configurations, Workflows and Screens From Test to Production

This page will advise how to effectively do this whilst minimizing the amount of effort that will be duplicated across the systems.  The sections that follow will provide information on how to:

1. Develop and test screens in test and export to Production
2. Develop and test Workflows and export to Production
3. Export Workflows from Production to Test
4. Implement System Settings/System Administration Change Control for your Production system

## Summary of the Process for Moving Work Packages from Test to Production

{% hint style="danger" %}

### Before you begin a new body of work - Back Fresh to Test

At this restore Point - No changes should be made in Production and concurrent projects developing in the newly refreshed Test system will need to Sync their timelines to allow for the Test Database to be refreshed without impact to one another.

###

### What should not be done in Production

1. Screen Changes
2. Workflow Changes

###

### What you can do in Production

1. System Administration Settings
2. Data Import (People, CMDB items, etc)
3. IPK Workflow Rules
4. Call Templates
5. IPK and Workflow Scheduling
6. Skins
   {% endhint %}

<table><thead><tr><th width="170">Item in ASM</th><th width="111">Item Type</th><th width="136">Where Stored</th><th width="175">Method of Moving</th><th width="168">Who Can Execute</th></tr></thead><tbody><tr><td>People Records</td><td>Data</td><td>Database</td><td>Manual/Import</td><td>Customer</td></tr><tr><td>Portal System</td><td>Data + Configuration</td><td>Database</td><td>Config Port/Import Screens/Manual (System Admin Settings)</td><td>Customer</td></tr><tr><td>Portal Skins</td><td>Screen Design</td><td>Database</td><td>Manual</td><td>Customer</td></tr><tr><td>Portal Menus (My Options)</td><td>Data</td><td>Database</td><td>Manual</td><td>Customer</td></tr><tr><td>Service Actions</td><td>Data</td><td>Database</td><td>Manual/CSV export/import</td><td>Customer</td></tr><tr><td>Services</td><td>Data</td><td>Database</td><td>Manual/CSV export/import</td><td>Customer</td></tr><tr><td>Stakeholder linkages</td><td>Data</td><td>Database</td><td>Manual</td><td>Alemba</td></tr><tr><td>Service Level Agreements</td><td>Data</td><td>Database</td><td>Manual</td><td>Customer</td></tr><tr><td>Email Templates</td><td>Screen Design</td><td>Database</td><td>Config Port/Import</td><td>Customer</td></tr><tr><td>Email Subject Headers (Email Subjects on Message Types)</td><td>Data</td><td>Database + Local XML Files</td><td>Config Port + Manual copy of XML FILes</td><td>Alemba</td></tr><tr><td>Email Processing Rules (IPK Workflow Rules)</td><td>Configuration</td><td>Database</td><td>Manual</td><td>Customer</td></tr><tr><td>Language Labels</td><td>Data</td><td>Database</td><td>CSV Export/Import</td><td>Customer</td></tr><tr><td>Workflows</td><td>Data</td><td>Database</td><td>Workflow Import</td><td>Customer</td></tr><tr><td>Screens</td><td>Screen Designs</td><td>Database</td><td>Config Port/Import Screens</td><td>Customer</td></tr></tbody></table>

## Terms Used

* The Production (PROD) system is the **master target system** - the final destination for all the changes being developed
* The Test (TST) system is the **source system** - where all the changes are developed

{% hint style="success" %}

### Best Practice

### Required Export / Import Sequence

The import and export sequence is critically important to a successful outcome. Follow these steps to ensure all changes are developed on the correct database and imported successfully to the master target system.

***For Cloud Clients: You will need to coordinate and Schedule this change work with Alemba so that the requisite backup and restore actions can be carried out as and when required.***

### ***Summary of Steps***

* [ ] Refresh Test with Production - Ensure the two are in Sync
* [ ] Start a Change Log
* [ ] Do the Development
* [ ] Update Change Log - Ensure all Changes are captured
* [ ] Do the Testing
* [ ] Log a ticket with Alemba Cloud Services at least 5 days in advance advising of the day and time you will push to Production if you are a cloud client - so that we can ensure a roll-back point is available for you.
* [ ] Promote to Production using the change log for manual changes and import utility for screens and workflows
* [ ] Regression Test

1. <mark style="color:red;">The first order of business is to Sync your Production and Test Databases.</mark> This is done by taking a copy of Production and restoring it to Test. **Copy the Production database to your Test environment before you begin any development.**
   * [ ] Perform data sanitization, if necessary, and wipe all email addresses from the AR\_Person table so that emails do not inadvertently go out, or, alternatively or in addition to, stop the Messaging Service. *Alemba Cloud Customers will have this done automatically as part of the back-fresh process.*
2. Develop the required screens, emails, and system setting changes on the TST system. When complete:
   * [ ] "**Save As"** the screens so that you get the HTML file.  Rename them accordingly. **Note:** If you created extension fields and linked them to the root entity screens you need export the root entity screens too even if no other changes were made.  Anything you touch, will need to be exported and thus included in the "Change".
   * [ ] **Export the Workflow Templates**. &#x20;
   * [ ] Populate the **Change log** (your spreadsheet) with the required System Administration Settings changes.
3. **Perform User Acceptance Testing and Regression Test any existing configurations you have changed**
4. <mark style="color:red;">**Move your Changes to Production**</mark>&#x20;
   * [ ] **Ask everyone to log out**, and verify by checking the Login Control in **System Administration ->Security -> Login Control**. &#x20;

     * Prevent new logins by Checking the Stop Logins box:

     <figure><img src="/files/TVBAHjBnW0tcIzkCMrXD" alt=""><figcaption></figcaption></figure>

     * You can log everyone out by ticking the **Logout all Analysts** icon ![](/files/OyFvwdOtXh0dhW5ns5nA)

     <mark style="color:red;">**CAUTION: Only log out all analysts if you are logged in on the master ADMIN account and not as an analyst yourself.  If you are using an analyst account, you should log each analyst out individually, instead.**</mark>

     * Optionally, you can email the Analysts and advise them they should save their work and log out by using the **Email Analysts** Icon ![](/files/tEwWoM9bVhifW84vPXZ3)
   * [ ] **Disable the Service Actions** that may be connected to screens or workflows you are importing to prevent users accessing them. To disable a Service Action, open the Service action and Change its status from "Service Catalog" to any other value that is not published to the Portal.
   * [ ] **Update the System Admin Settings** creating the screen sets (if required) and making sure all other settings are in place as recorded in the Change Log.
   * [ ] **Import the Screens**. **Note:** If you created extension fields and linked them to the root entity screens you need to first import the root entity screens even if no other changes were made, and then your new screens.  Anything you touch, will need to be exported/Imported and thus included in the "Change".  **The reason to import the root entity screens first is so that your linking between the screens can be maintained.**
   * [ ] **Validate any screen rules** that are needed
   * [ ] **Import the workflows**.
5. **Regression test** to ensure the import was successful
   * If testing reveals there were problems with the changes or the import, go back to Step 2 and try to assess where the disconnect happened and correct it.
6. Once the import is done and you have verified that everything is working, **re-enable logins and the service action(s).**
   {% endhint %}

{% hint style="success" %}

### Best Practice

### Back up the Target environment(s)

* Backup routine should always occur to facilitate rollback if needed
* If using a VM, you can snapshot the VM
* Cloud Customers should log a ticket with Alemba Cloud Services at least 5 days prior.
  {% endhint %}

{% hint style="success" %}

### Best Practice

### Code and configuration freeze on Target environment(s)

* Configuration changes should only be made on the Source system (TST)&#x20;
* Manual changes should not be performed on Master Target (PROD)&#x20;
  * Manual changes risk being overwritten by the process
    {% endhint %}

{% hint style="success" %}

### Best Practice

### Be specific

* Only export and import the specific elements you need
  {% endhint %}

## Typical Mistakes that can cause data corruption

1. Source (TST) and other Targets are not synced with the Master Target (PROD) before development starts
2. Importing files from multiple environments into Master Target (PROD)
3. Importing in the wrong sequence
   * For example, if you import a workflow that needs custom screen sets that have not yet been created in the System Administration settings or imported into designer, then the workflow will come in "fractured" because the screens it needs are not present.
   * You cannot import screens until the screen set has been created in System Administration because there is nothing to link them to yet.
   * Similarly, if that workflow has rules written that depend on values in a DropDown configured on either the screens or the System Administration settings, such as Request Phase, etc and they do not exist, this will also create a situation where your imported workflow will not work. &#x20;
   * **Always import/reconfigure in this order: System Admin Settings -> Screens -> Workflows.**

{% embed url="<https://docs.alemba.com/asm/setup-and-configure-asm/designing-configuring-your-system/configuring-screens/building-screens-in-asm-designer/importing-exporting-screens>" %}

{% embed url="<https://docs.alemba.com/asm/~/changes/o2bty0OsPcN65aWqKod5/setup-and-configure-asm/setting-up-your-system/system-administration-settings/ipk-and-workflow/workflow-management/workflow-porting>" %}

### Spreadsheet Template for Tracking System Administration Changes

Alemba can provide a template for you to use that will include the options for documenting your system.

{% file src="/files/FclSlGrbvwd81kCy5YYu" %}

## \*\*Alemba Cloud Customers

Alemba Cloud Customers will need to contact Alemba through the Self-Service Portal and coordinate the back-fresh from Production to Test as and when needed.  Please try to give a 5-day advance notice so that it can be scheduled.

{% @arcade/embed flowId="cdroHr6mZL77Xmgeo1ao" url="<https://app.arcade.software/share/cdroHr6mZL77Xmgeo1ao>" %}


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.alemba.com/asm-legacy-product-documentation/setup-and-configure-asm/moving-configurations-workflows-and-screens-from-test-to-production.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.