Skip to main content
Vortex has support for two environments, development and production. Development is where you’ll make, preview and test your changes. In fact, if you have an invitation form already installed in your application, and you are currently viewing it, any changes you make to the form on Vortex will appear in your application without even having to reload the page. When you’re ready to put your changes in from of your users, you will publish them to production. The Publish tab in your invitation flow will walk you through some important steps.
  • Production API Key - You will have already copied your development API key as part of installation, but before you go to production you’ll want to make sure your production API key is being used in your production environment.
  • Landing Page - Similarly, you will have specified a development landing page (i.e., the page that your invitation links point to) during installation, but now you’ll want to specify the production version of that URL.
  • Publish - Depending on the state of your invitation flow you will have one or more of the following actions available to you:
    • Publish - Publishes your changes for 100% of users.
    • Run A/B Test - Once the first version of your invitation flow has been published, subsequent changes can be A/B tested against a preceding version instead of being pushed out to 100% of users.
    • Rollback - Only available once you have at least two published versions of your invitation flow, this allows you to roll back to an earlier version.
    • Declare Winner - When there’s an active A/B test, you can declare a winner by publishing one of the versions for 100% of users.
  • Send Test Invite - Once you’ve published, it’s always a good practice to send a test invitation in production to make sure everyting is working.

​
Versioning

When you publish changes the version number of your invitation flow, which is displayed to the right of its name, is automatically incremented. Subsequent changes will add the unpublihsed indicator (i.e., blue dot) to the right of the version number until those changes are published. Put another way, changes are always published as a new version. There’s no way to edit or update a version once it’s been published. You simply publish new changes. It’s also important to note that any changes you publish only impact NEW invitations, and not existing inviations. Let’s look at an example. Say version 1 of your invitation flow has three reminder emails, but you decide that you’d like to try just two reminders. After you make this change and publish it as version 2 of your invitation flow, anyone invited from that point forward will get just two reminders. However, anyone invited via version 1 of the invitation flow will continue to get three reminders. All elements of a specific version of an invitation flow apply to all invitations generated by that version of the flow, and don’t change with the publishing of a new version.

​
A/B Tests

Whether you’re adding new features to your invitation form or refining the tone of your invitation emails, Vortex makes it easy to update your invitation flow. Instead of shipping changes and hoping for the best, Vortex’s built-in analytics and A/B testing enable you to make confident, data-driven decisions. And because changes don’t require developer involvement, you can move from infrequent, high-risk updates to a continuous cycle of testing, learning, and optimization. Whenever you publish updates to production, you can choose to run an A/B test against a preceding version of the invitation flow rather than rolling changes out to all users at once. By default, traffic is split evenly between versions, but you can customize the distribution to expose changes to a smaller percentage of users if desired. As your test runs, you can use the Version filter in the Analytics section to track performance for each variant in real time, giving you the insight you need to confidently declare a winner. For best results, we recommend running A/B tests for at least one week to account for day-of-week variability.