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 clear visual way to make the dialogue status known. See Best practices for naming and labeling objects in BlueConic.
- Have test environments? Use them!
With settings in the dialogue's 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 in the article 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 ensures that statistics 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.