Overview
This post provides general guidance for customers participating in the EU hosting beta for Flow Production Tracking (Flow PT).
During this beta, customers will test a staging Flow PT site that has been migrated to the EU region. The goal is to help evaluate two things:
- Whether your EU-hosted staging site feels faster, slower, or about the same compared to your production site
- Whether key workflows continue to function as expected in the new hosting region
Testing with a staging site
During the beta period for EU hosting, a Flow PT staging site will be migrated to the EU region for testing. If you do not already have a staging site, or if you are not familiar with staging sites, the sections below explain what they are, how to create one, and how they should be used during beta testing.
What is a staging site and how do I get one?
A staging site is an additional Flow PT site that is entirely separate from your production Flow PT site, but runs on the same infrastructure and has the same performance characteristics as a production Flow PT site.
Staging sites are typically used to test new changes, workflows, or integrations before applying them in production, helping reduce the risk of disruption to your users.
If you do not already have a staging site, you can create an additional Flow PT site by following the process described in Autodesk’s documentation for creating an additional site for your team.
When creating a staging site, please use a naming convention that matches your production site URL with the addition of -staging. This can be shortened to -stg if needed.
For example, if your site URL is:
https://mysite.shotgrid.autodesk.com
your staging site should be named:
https://mysite-staging.shotgrid.autodesk.com
Once your staging site has been created, we will clone the contents of your production site to the staging site and then migrate that staging site to the EU region.
Please note the following:
- Media is not typically included in the cloning process, though this can be evaluated on a case-by-case basis if you need to test workflows that depend on media.
- Cloning is a one-time operation, although it can be repeated later if needed.
- Data does not continuously sync between production and staging after the clone is completed.
- Changes made on one site are not reflected on the other unless a new clone is performed.
How does access to Flow PT staging sites work?
Seat assignments from your production Flow PT site will be cloned to your staging site. This means that any users who can access your production site when it is cloned will have access to the staging site as well.
Flow PT subscriptions and flex tokens can be shared between sites that belong to the same team. As a result:
- Users with a Flow PT license can access both your production and staging sites with no additional cost.
- A user active on multiple sites within the same team requires only one license.
- For token-flex customers, one user active on multiple sites on the same day will only use tokens once for that day.
How do we use a staging site for testing?
Because your staging site is cloned from production, some workflows can be tested directly using the cloned data. This includes activities such as:
- Browsing and editing data in Flow PT
- Opening pages and records
- Viewing or creating reports
- Validating general site behavior and responsiveness
If you would like to test custom pipeline tools or integrations, those tools must be configured to connect to the staging site rather than your production site.
For example:
- For Python scripts, this typically means updating the site URL used when establishing the Flow PT connection
- For REST API integrations, this generally means updating endpoint URLs so that requests are sent to the staging site rather than the production site
Many customers manage this by storing both the production and staging site URLs in configuration constants and using a switch such as an environment variable to control which site is used by a given tool or integration.
Testing Guidelines
How and what to test
Once your staging site has been migrated to the EU region, please use it to test the workflows that best represent how your studio normally uses Flow PT. At a minimum, we recommend validating site access, general responsiveness, and one or more workflows that are important to your studio. Detailed feedback should be submitted through the beta questionnaire provided as part of this program.
Before you begin
Before starting your tests, please confirm the following:
- You have the correct staging site URL.
- The users participating in testing are able to access the staging site.
- Any custom tools, scripts, or integrations that you intend to test have been updated to point to the staging site instead of your production site.
- You understand whether media was included in the site clone, if media-based workflows are part of your testing plan.
When comparing your production and staging sites, try to test from the same location, network, and general time of day whenever possible.
If your staging site has not been used recently, we also recommend performing a few simple actions before evaluating performance, such as logging in, opening a page, or viewing a record. Staging sites are often not used as frequently as production sites and may be “cold.” In these cases, the first request may take longer while resources are allocated. Running a few initial actions will help produce more representative test results.
Because every studio uses Flow PT differently, there is no single test plan that fits everyone. Instead, we recommend starting with the core tests below, then testing any additional workflows that are important to your team.
Core tests
At a minimum, we recommend testing the following areas.
- Site access and login: Confirm that users are able to sign in to the staging site and that access works as expected. This includes validating that the appropriate users can access the site and that permissions appear to match your expectations based on the cloned production configuration.
- General page navigation: Open and move through the pages your team uses most often. This may include navigating between projects, opening entity pages, switching between tabs or views, and browsing records to confirm that the site feels responsive during normal use.
- Editing and saving data: Test common actions that involve updating existing records or creating new ones. This may include editing fields, adding notes, updating statuses, assigning tasks, or making other routine changes, then confirming that those changes save and display as expected.
- Creating or updating pages, filters, and views: Test any common administrative or user-level configuration work your team performs in Flow PT. This may include creating or modifying pages, adjusting filters, updating saved views, or confirming that existing configurations behave as expected in the staging site.
- Checking reports and canvas page performance: Open the reports or canvas pages your team uses regularly and confirm that they load successfully and display the expected information. This is also a good opportunity to evaluate how responsive these pages feel compared with production, especially for more complex or data-heavy views.
- Uploading and viewing media: If media workflows are part of your normal usage and media is available in the staging site, test uploading media and viewing existing media where applicable. This can help confirm that media-related workflows behave as expected in the EU-hosted environment.
- Representative day-to-day workflows: Test one or more workflows that reflect how your studio normally uses Flow PT. For example, this may include production tracking, review coordination, scheduling-related workflows, or other activities that are important to your team’s day-to-day operations.
- Additional integrations: If your studio uses custom tools, scripts, or API-based integrations, you may also wish to include those in your testing after updating them to point to the staging site.
Where should we expect to see performance improvements?
In general, migrating a Flow PT site to EU hosting should reduce latency for users who are based closer to the EU than to North America. This may improve the general responsiveness of Flow PT’s UI and reduce response times for API requests.
However, it is important to note that not all aspects of Flow PT’s performance are driven by network latency alone. Other factors can also affect response times, including:
- The amount of time required for the backend to gather and return data
- The complexity of the page or query being loaded
- The amount of time required for the browser to render the page
- The behavior of custom configurations, integrations, or workflows
For example, a very complex custom page may involve time spent gathering a large amount of data, sending that data to the browser, and rendering the results. In such cases, reduced latency may improve only part of the total load time, and the overall change may be modest.
For that reason, we are interested in both measurable results and your experience using the site. Even if measured latency improves, it is still valuable to know whether the site actually feels faster during day-to-day use.
What feedback is most helpful?
As you complete your testing, please make note of the following:
- Whether the staging site felt faster, slower, or about the same as production
- Which workflows showed the most noticeable difference in responsiveness
- Whether any workflow failed or behaved unexpectedly
- Whether any custom integrations required additional changes beyond pointing them to the staging site
- Where the testers were located when testing was performed
This feedback helps Autodesk evaluate both measurable performance changes and the overall user experience.
Responses should be submitted through the beta questionnaire provided.
Thank you for your interest and participation!