User Management
Audience:
Low-code EngineersSkill Prerequisites:
Actions,Tokens,Users
The User Management add-on adds actions that work with the site's user accounts. They create accounts and sign users in, send reset password emails, give and take away roles, authorize, unlock and delete accounts, and change usernames and profile data. They work through DNN's own user accounts, the same ones you see in the Users admin page.
These actions are part of the User Management add-on (PlantAnApp.UserManagement, product code USRMGR). The add-on is installed separately. The actions don't check the license when they run. If you don't see these actions in the User Management group, the add-on isn't installed.
Some actions in the User Management group come from elsewhere. User Reset Password and Validate User Reset Password are part of Forms. See User Management. User Login (MS Active Directory) is part of the Active Directory add-on, and User Login (OpenLdap) is part of the OpenLDAP add-on.
Choosing an action
Registration and sign-in
| Action | What it does | Use it to |
|---|---|---|
| User Registration | Creates a user account, authorized or not, and makes it the current user. It doesn't sign the user in. | Build a custom registration form, or add users from an admin screen. |
| User Login | Signs a user in with a site username and password. | Build a custom login form, or sign a user in right after User Registration. |
| User/Password Validation | Checks a username and password, and optionally a role, without signing the user in. Saves True or False in a token. | Ask a user to confirm their password before a sensitive change. |
| Create Auto Login Link | Creates a link that signs a user in without a password and opens a page you choose. | Send a one-time, short-lived link in an email. Read its security notes first. |
| Send User Reset Password Email | Creates a new reset token for the user and emails them a link to your reset page. | Run a "Forgot password" form, or let an admin send a reset link. The reset page itself uses the Forms actions. See How the reset password flow works. |
Roles
| Action | What it does | Use it to |
|---|---|---|
| Grant User Role | Adds users to roles in the current portal, forever, for a number of days or between two dates. | Give a new user a role, or give access to a paid area for 30 days. |
| Revoke User Role | Removes roles from users. | Remove a trial or subscription role when a user cancels. |
Account status
| Action | What it does | Use it to |
|---|---|---|
| Authorize User | Authorizes users, so they can log in. | Authorize a user after they confirm their email, or after an approver accepts them. |
| Unauthorize User | Unauthorizes users, so they can't log in. The account and its data stay. | Suspend an account without deleting it. |
| Unlock User | Unlocks an account that was locked out, for example after too many failed logins. | Let an administrator unlock a selected user. |
| Delete User | Deletes every user in the context's list of users, from the portal or from the database. | Let a user delete their own account, or clean up old accounts in a scheduled job. |
Profile, portals and cache
| Action | What it does | Use it to |
|---|---|---|
| Update User Profile | Changes one user's password, display name, email and profile properties. | Build a "My Account" form, or save extra data after User Registration. |
| Update Username | Changes one user's username. | Let users pick a new username, or keep usernames in step with email addresses. |
| Sync Users | Adds users to other portals, with the roles that have the same names there. It never removes anything. | Share users between portals, for example in a scheduled job. |
| Clear User Cache | Removes DNN's cached copy of a user, so fresh data is read from the database. | Show a user's new data after changing user or role tables with SQL. |
Which users an action changes
The actions pick their users in different ways. Check this before you run one, especially the ones that change more than one user.
| Users changed | Actions |
|---|---|
| The current user, plus every user in the context's list of users | Authorize User, Unauthorize User, Revoke User Role, and Grant User Role when To User is empty |
| Only the users in the list | Delete User |
| One user you name, or the current user if you leave it empty | Update User Profile, Update Username, Clear User Cache |
| One user you name | Grant User Role with To User, Unlock User, Send User Reset Password Email, Create Auto Login Link |
| One user, by username only | User/Password Validation |
| Users by ID, on the portals you list | Sync Users |
- The current user is usually the logged-in user. Load User and Change User change it. After User Registration or a successful sign-in, it's the new or signed-in user.
- The list is filled by Load User and Load Users from SQL. It starts empty, and users loaded earlier in the same run stay in it. Change User doesn't add to it.
- Naming a user. Where you enter a user, a number is treated as a user ID. Otherwise it's matched against email addresses, then usernames, on the current portal.
- Load, then check. To change another user, load them first and add a condition that checks the right user was found, for example
"[User:UserID]" == "[UserId]". Otherwise an action that also changes the current user can change the person who clicked.
Who can run these actions
Most of these actions don't check who is running them. Anyone who can run the action list can, for example, grant Administrators, delete or unauthorize the loaded users, rename another user, or create a sign-in link for any account.
- Put actions that change other users only where administrators or other trusted users can reach them, or add a condition that checks the caller's role.
- Don't build user identifiers or role names from values a visitor can change, such as form fields, the query string or API parameters. On public forms, leave the user empty so people only change their own account, and hard-code the roles.
- Several actions show different errors for known and unknown accounts. Catch errors with Execute Actions and show one general message where that matters, for example on a "Forgot password" form.
- Use HTTPS on any page where users type a password.
Web requests and Automation
Some actions need a browser, so they don't work in Automation jobs, such as workflows and scheduled jobs:
- User Login isn't available in Automation, because signing in needs a browser to receive the login cookie.
- Update Username isn't available in Automation.
- The Send standard registration email option of User Registration only sends from forms and listings. Use Send Email elsewhere.
Actions that work on loaded users, such as Authorize User, Unauthorize User, Delete User and Sync Users, suit scheduled jobs. Load the users with Load Users from SQL first. Send User Reset Password Email also works in a workflow, for example for users created by an import.
Suspend, remove access or delete?
- Remove access to one area. Use Revoke User Role. The user can still log in.
- Stop the user from logging in. Use Unauthorize User. Authorize User undoes it.
- Remove the account. Use Delete User. Without Hard Delete, the account stays in the database marked as deleted, so its username and email may not be free for a new account. A hard delete can't be undone.
Users who sign in with Active Directory or OpenLDAP are signed in even if their site account is unauthorized or locked. Block them in the directory instead.
To load users, see the Context actions. To create, change or delete roles, see the Security actions. For all add-ons, see Add-ons.
Revised 10/02/2026