In these docs: Custom Database Action Script Execution Best Practices
There is a section that says:
Use a rule to mark users as migrated. This is not a hard requirement, but it does protect against one scenario in which a user changes their email address, then changes it back to the original email address. A rule should call out to the legacy database to mark the user as being migrated in the original database so that get_user can return false.
In the context of a rule, is there an out of the box way to tell if a user was migrated vs. newly registered directly in the Auth0 managed database? The way that section of the docs is written implies there is some straighforward way to do this.
Thanks.
In your lazy migration script, populate an app_metadata field something like “migrated_from_legacy”: “true”
This will only be populated then for users who are migrated.
John
How do you recommend handling the edge case where app_metadata is not properly populated from the database action script? I was thinking of appending text to the user_id e.g. “_migrated”.
From your docs:
If setting app_metadata or user_metadata, use a rule to fetch the metadata if it is missing. The metadata is not migrated until https://YOUR_TENANT.auth0.com/login/callback is called. However, the user credentials are migrated during the post to usernamepassword/login. This means that if the browser is killed or computer dies on a user after they have posted to usernamepassword/login, but before login/callback, then they will have a user in the Auth0 database, but their app and user metadata are lost. It is really important, therefore, to create a rule that looks a lot like your get_user script to fetch the profile if app and user metadata are blank. This should only execute once per user at most (and usually never).