Best Practice on Avoiding Production Configuration Errors

Logging in to Production is necessary when you need to investigate live recipients' data or when reporting on a live send-out. If you do any types of configuration directly on Production, you run the risk of causing a number of issues due to incorrect workflow. You can also read our documentation about best practices on Workflow here.

Below, you'll find some of the common errors that can occur from working directly on Production and the solutions we suggest to avoid them from happening.

In this article, you'll find information about:

• Agillic's Best Practice on Avoiding Production Configuration Errors
  • Publish Failing Due to Duplicate Name
  • Publish Failing Due to Reference
  • Changes Made Are Overwritten Upon Publish
  • Items Cannot Be Selected on Staging
• Reasons to Work on Production
  • Investigating Live Recipients
  • Creating an Activity Export Which Exports to an FTP or SFTP Server

Agillic's Best Practice on Avoiding Production Configuration Errors

The steps below are here to highlight incorrect workflow behavior and should not be recreated. Therefore, we advise you not to follow the steps below.

Publish Failing Due to Duplicate Name

Your Publishes will fail if you configure in the following way:

• Create an item on Production and name it.
• Create an item on Staging with the same type and the same name.
• Make a Publish to Production.

To avoid this, you should always configure and create items on the Staging environment and then Publish to Production.

Publish Failing Due to Reference

Your Publishes will fail if you configure in the following way:

• Create an item on Staging such as a Target Group.
• Make a Publish to Production.
•  Create a Target Group on Production and add a Target Group Condition to the Staging Target Group. This creates a Target Group reference.
• Delete the Target Group you created on the Staging environment.
• Make a Publish to Production.

In these examples, the Publish will fail as the Production-only Target Group has a reference to a non-existent Target Group. To avoid this, do not edit Target Groups made on Staging on Production. Instead, make all your configurations on the Staging environment and then Publish the changes to the Production environment.

Changes Made are Overwritten Upon Publish

Your changes will be overwritten if you configure in the following way:

• Create a Target Group on Staging.
• Make a Publish to Production.
• Change the Target Group on Production.
• Make a Publish to Production.

Changes made (and saved) on Production are overwritten by the version on Staging. To avoid this, only make changes to the Staging environment and then Publish to Production.

Items Cannot Be Selected on Staging

You cannot select an item on Staging if you work in the following way:

• Create an item on Production such as a Target Group.
• Create another item on Staging such as a Flow.
• Attempt to add the Production-only Target Group to the Flow on Staging.

You'll be unable to add the Target Group to the Flow as it only exists on the Production environment and not the Staging environment.

Attempting to fix this can also lead to a series of issues:

• If you publish the Flow to Production and then add the Target Group directly on Production, you'll remove the Target Group from the Flow following the next Publish.
• Creating the Target Group on Staging with the same name of the Production-only Target Group will result in the next Publish failing.

To avoid this, only Create Target Groups and Flows on Staging and then do a Publish to Production. 

In general, we advise you to not do any changes to Data fields such as Person Data fields, One-to-many Tables, or Global Data Tables on Production. Also, do not change the uniqueness of any data fields on Production as this can create discrepancy errors between Staging and Production.

Reasons to Work on Production

Though our best practice is to always work on Staging, there are a few scenarios where it can be necessary to work directly on Production. They include:

Creating a Report on a Live Send-out

Since data on Staging and Production are separate, you'll need to log into Production to, for example, report on a live send-out. This is not possible from Staging.

Investigating Live Recipients

Since data on Staging and Production are separate, you'll need to log in to Production to investigate live recipients' data. If you need to create a Target Group directly on Production for this purpose, you should make sure that you do the following:

• The Target Group name is only created on Production and differentiated as such by using a Production-only naming convention, such as 'New_TG_Prod_Only'.
• The Target Group isn't connected, referenced, or used in any other item on Production.

If you don't follow these rules, you may experience the Production errors described above.

Creating an Activity Export which Exports to an FTP or SFTP Server

If you create an Activity Export which exports to an FTP or SFTP server on Staging, the Activity Export will generate on both environments and will cause two files to send to the FTP or SFTP server. Because of this, it can make sense to create the Activity Export directly on Production.