BlueConic dialogues are powerful. Some are simple, and lightweight testing may be appropriate. For more complex situations, we recommend following a development and testing pattern. The pattern may differ wildly depending on your own internal development processes, but no matter the path it should be possible to incorporate the practices outlined within this document to ensure dialogues are not promoted to production before they are ready.
Good examples of when to apply this kind of workflow include any large-scale modifications to page content, such as inserting product recommendations or content recommendations.
- Know your stages
At the least, have a development and production stage. Consider adding a testing stage as well, to make it clear when development is complete.
- Use labeling or tagging
Use BlueConic labels or apply some kind of tagging convention in dialogue names. Or both. These will come in handy when searching or saving filter sets, and having a tag in the name (e.g. [DEV]) is just a nice clear visual way to make the dialogue status known.
- Have test environments? Use them!
With settings in the "where" tab, you can aim a dialogue at the appropriate environment each step of the way. Whether you have test environments or not, make sure you take a two-step approach when attempting to review a dialogue in a limited fashion. Use both a "who" tab restriction and a "where" tab restriction to add one level of protection in case of error in situations where you should be the only one who can see a dialogue. Techniques for reviewing dialogues are described here: https://support.blueconic.com/hc/en-us/articles/202876772-Reviewing-dialogues-in-standard-browsers
- "Save as" by stage
Use "Save as" along each stage of your development path. Change the "where" tab and any labeling. This will ensure stats are kept per stage, and it will leave a version of the dialogue that can be referenced or re-deployed later in case there are any questions.