Workflow Using Virtual Staging
On this page
Virtual staging environments are designed to support a wide range of different workflows and business rules.
Watch the video below to see how Virtual Staging can fit in with your workflow. More examples of how your workflow can be enhanced are explained in more detail below.
Video: Using Virtual Staging to enhance your workflow
In the example of the "Launch environment" introduced on the Creating a Virtual Environment page, the lifecycle of assets would typically be as follows:
The assets for the launch project are uploaded to the "Launch assets" asset store in Content Hub. Only authorised users would be able to access this store.
These assets would then be reviewed from a web browser, mobile app or ecommerce integration with access to the assets managed by the virtual staging environment. To make it easy for users, you might want to provide a UI to switch between the staging environment and production. The base domain of the staging URL, for example, zllu2w1z3lx51q8lxlzgzj5gr.staging.bigcontent.io would be used instead of the base URL of the production domain i1.adis.ws. The rest of the URL for an asset will be the same.
The workflow video included above shows an example of separate development, staging and production environments that can you switch between simply by changing the base domain in the URL.
When requesting an asset with a staging URL, the staging service will check that the requesting IP address is specified in the white list set up for this environment. See the VSE security page for more details.
When everything has been reviewed and approved, the content will be published to production. This might involve running a script to automatically publish everything in the "Launch assets" store, or only those assets updated between certain dates, depending on what business rules you want to implement. The published assets would then be accessed using the production URL.
Note: It is currently not possible to prevent users from publishing from a specific asset store.
Here are just some of the ways in which Virtual Staging Environments can adapt to and improve your existing workflow.
Preparing assets for the next season
In this example, one team is working on maintaining content on the live site while another is preparing content for the next season. The assets for the next season are uploaded to an asset store in Content Hub named "SpringCollection". A new virtual staging environment is created with rules that specify that assets should first be loaded from the "SpringCollection" store and if this is not found then the asset should be loaded from the live production assets. The team work on the new collection assets within the staging environment and when the work is complete and reviewed, the assets in the "SpringCollection" can then be published to production. The cycle will then continue with the next season's assets.
If an update was required to an asset on the production website, then this could be uploaded to the asset store used for production and then published, but requesting the same asset from within the next season's virtual environment would still return the asset from the "SpringCollection".
Previewing a "hot fix" before production
In some cases you might want to preview changes made to a production site before it goes live. One way of doing this would be to create a staging environment with a rule that pulls assets from the asset store used for production assets. In this example, the production assets are stored in the asset store named "Assets".
The updated assets will be uploaded to this store as normal but not published. The staging service pulls the content directly from the asset store, allowing you to review it before it is published to the live site.
Supporting multiple parallel projects
If you have multiple teams working on parallel projects then it's possible to create a staging environment for each team, each with its own rules and its own asset stores. These teams would then be able to work independently of each other and not interfere with any other team's workflow.
In the example illustrated below, the content team want to be able to preview content before it goes live, while the QA team wants to work in a separate environment to the content team and not interfere with the content team's work. The QA team can create their own VSE, with content rules that specify that assets should first be looked for in the QA Team asset store, then the asset store being worked on by the content team and finally the live production assets. The content team creates their own VSE that just includes that asset store that they are working with and the production assets.
You can create several staging environments and work with them in parallel, providing the flexibility to support many possible business processes.