Introducing Rules Migration Tooling

[rueben.tiow]

Hello Community team!

We are now releasing a new Rules migration tooling! Migrating from Auth0 Rules to Actions is a straightforward but essential task due to the planned deprecation of Rules. With the latest migration tooling release, this task has been made super simple. We strongly recommend that you first verify the conversion from your Rule to Action in a non-production Tenant and, once satisfied, only then proceed to migration on your production tenant.

Here’s a concise guide on how to perform the migration:

1. Identify the Rule to Migrate: Start by selecting the specific Rule you want to convert form within Auth Pipeline > Rules section of the Auth0 dashboard. Keep in mind that the order in which you migrate over Rules matters, so you can pick the last Rule first as Actions execute after Rules, so you wont break your current execution order.

   • Select Migrate to Action: You will see the button “Migrate to Actions” against the respective rule to start the process

     • Give the target Action a descriptive name
     • Select the preferred Run time (Node 18 is recommended)
       
       

   • Alternatively you can create a new Actions yourself or select an existing Action and from there you can access the “Rules” menu in the left nav of the Actions editor and select the Rule to migrate
     

2. Rewrite the Rule as an Action: At this stage you will be at the Actions editor page with a split window showing the Rule to migrate alongside the Action you can author.

   • We will automatically identity and highlight syntax differences within the Rules window
   • You can simply copy the Rule’s code over to the Actions section and see the same highlighted sections of your code which require modification
   • Now you can hover over the highlighted parts and select “Quick Fix” to get a recommendation on how to update to Actions compatible syntax.
     
     
     
     Selecting a recommendation from Quick Fix (where available) will automatically replaces the old Rules syntax with the recommended Actions syntax. For some cases you may not find a Quick Fix option, but instead an explanation on how to address the difference.
     
     
   • Address all the highlighted parts and now you’re new Actions code is ready for next steps.

3. Validate the Action: You can now use the Actions test feature to simulate a transaction and verify that the Action is working as intended. You can find more details on how to test Actions which have not been deployed as yet.

4. Deploy and Integrate: Once validated, proceed to deploy the Action and drag it into the appropriate Login flow in the Auth0 dashboard.

   • You would have noticed that the we had automatically added a condition that would prevent the new Action to execute if the corresponding Rule was still active which makes it safe to deploy at this stage.

if (api.rules.wasExecuted("<ruleId>")) { 
	return;

5. Disable the Old Rule: Now proceed to disable the old Rule and run an actual transaction to validate the Action is functional as expected. Once satisfied, you can leave the Rule in a disabled state, otherwise you can debug leveraging details provided here.

For more detailed guidance and examples, you can refer to the official Auth0 documentation on migrating from Rules to Actions.

[kamil.burek]

Is there any movement on publishing the Auth0 Actions official type definitions that are used on the live code editor? Especially now that they include suggestions for Rules migration?

So far I’ve managed to extract all of the PostLoginV3.d.ts and other files via dev tools by mangling some base + trigger specific definitions together that are loaded on the page, but it’s been a pain and definitely not a sustainable option.

[rueben.tiow]

Hi @kamil.burek,

The Post Login Action documentation contains information about the Event and API objects, from which you can infer the type definition of the described properties.

See:

• Actions Triggers: post-login - Event Object
• Actions Triggers: post-login - API Object

Thanks,
Rueben

[kamil.burek]

Hi @rueben.tiow,

Yes, I understand that, unfortunately that does not address the question. I am referring to getting type definitions available in local IDEs, for example by publishing them under @types/ on NPM or elsewhere, for example as a part of the existing node-auth0 package.

There were already other requests for this:

• Types developing actions locally
• Public type definitions availability
• Publish Types for Writing Auth0 Actions in external IDEs

Currently we have some local scripts to munch through the vendor.js file from Auth0 Actions online editor page and generate the following files for each type (trigger) which we can then use within our code repository:

• CredentialsExchangeV2.d.ts
• LoginPostIdentifierV1.d.ts
• PasswordResetPostChallengeV1.d.ts
• PostChangePasswordV2.d.ts
• PostLoginV3.d.ts
• PostUserRegistrationV2.d.ts
• PreUserRegistrationV2.d.ts
• SendPhoneMessageV2.d.ts

I appreciate that the online Actions editor experience is great with new features like the Rules migration suggestions, although changes alike do not have any impact when used outside of that site, e.g. in IntelliJ or VSCode. Growing support things like Auth0 provider for Terraform is enabling teams to work on Actions more effectively and securely. For example, we would like to limit global access to Auth0 Dashboard and manage changes with source control and CI, however that is not really possible if the development experience outside of the Actions editor is poor without type definitions, type checking, code completion, etc.

[kamil.burek]

Hi, any movement on externally available type definitions to improve migration tooling?

[Molly878]

Your thorough explanation was incredibly useful. Thanks for taking the time to share it.