# Command Action

Command actions allow you to run & enable/disable other commands you have.

When running another command, it will be run as the user who triggered the currently running command. After you have selected a command, you can also specify what arguments to use with the command. If no arguments are specified, the currently running command's arguments will be used. You may also use [Special Identifiers](/docs/reference/special-identifiers) in the Arguments field.

When running a command via the Command Action, it runs the actions within the selected command. Whether it *also* enforces that command's Usage Requirements is controlled by the **Ignore Usage Requirements** toggle, which is turned **on** by default for a newly-added Command Action. This means that, by default, the sub-command's Usage Requirements (such as Moderator-only permission checks, cooldowns, and so on) are **not** checked. For example, let's say you're trying to run a shoutout chat command that has Moderator permissions on it. Run via a Command Action with the default settings, it will *not* check whether the user has Moderator permissions. If you uncheck "Ignore Usage Requirements", the sub-command's requirements are then validated just as if it had been triggered directly. So it's important to consider how you have your commands set up and what type of commands they are. Do note that things like Usage Requirements don't exist on all command types, such as Action Groups, which makes them ideal for this sort of behavior.

By default, the action will **wait** for the selected command to finish before moving on to the next action. This can be changed by toggling the "Wait Until Complete" option. When a Command Action waits until the selected sub-command is completed, the sub-command WILL NOT use the built-in command locking system for this specific time it is run. This is to prevent what's known as a deadlock (command gets stuck and can't complete). This also means that other commands of the same type as the selected sub-command will be able to run at the same time if it's different than the current command. For example, if the selected sub-command is an Action Group, then it will still be possible for another Action Group to run at the same time if this is enabled. You can think of it as similar to toggling the "Unlock Command" option, but it instead only applies to this specific time.

This action supports the following options:

- **Run Command:** Runs the specified command
- **Enable Command:** Enables the selected command
- **Disable Command:** Disables the selected command
- **Toggle Command:** Toggles the state of the command between enabled and disabled
- **Enable Command Group:** Enables all commands in the selected group
- **Disable Command Group:** Disables all commands in the selected group
- **Cancel All Commands:** Cancels every command that is currently either pending (queued) or already running, not just the queued ones
- **Pause All Commands:** Pauses all currently pending and future commands
- **Unpause All Commands:** Unpauses all currently paused commands
- **Pause All User Entrance Commands:** Pauses user entrance commands specifically. Entrance commands triggered while paused are queued up instead of run
- **Unpause All User Entrance Commands:** Unpauses user entrance commands and runs any entrance commands that were queued up while paused
- **Set Command Cooldown:** Manually sets the cooldown for the command based on the type of cooldown it has set for it.
- **Exit Current Command:** Immediately stops the current running command. If the current command is part of a chain of commands (EX: Command A triggered Command B), it will only stop the command that has this action in it and not any previous commands in the chain.