The objective must exist and use the trigger criterion. Setup 1 on the right creates it with this exact name.
Plain /trigger adds 1 to the player's score in the objective. This is the form players type for one-shot actions like /trigger home.
Used by Setup 2 on the right. /trigger itself takes no target: it always changes the score of the player who runs it. Using the trigger disables it again for that player, so most maps re-run the enable command on a repeating command block.
Adds 1 to the runner's home score. Works for any player without op, as long as the objective is enabled for them.
Run once as an operator or from a command block. The trigger criterion is what makes the objective usable by non-op players.
Without this the player command fails with 'You cannot trigger this objective'. Repeat it after every use, or put it on a repeating command block.
Detect the score with a command like execute as @a[scores={home=1..}] at @s run ... then set the score back to 0 and re-enable. That loop is how TPA, home and vote systems run on vanilla servers.
/trigger is the one scoreboard command every player can run, op or not. It changes the runner's own score in a scoreboard objective with the trigger criterion: plain /trigger adds 1, add adds any value, set writes a value directly. Servers and maps watch those scores to build chat commands like /trigger home, /trigger tpa and /trigger vote out of pure vanilla.
Normal scoreboard commands need permission level 2, so a regular survival player cannot touch scores. The trigger criterion is the deliberate exception: /trigger runs at permission level 0, works with cheats off, and can only ever change the score of the player who runs it. That makes it safe to expose and perfect as a player-facing button: the player types a short command, the score changes, and an operator-side detection loop reacts with the real commands.
The catch is that a trigger objective must be enabled for a player before they can use it, and using it disables it for them again. That is what the two setup commands in the generator above are for: one creates the objective with the trigger criterion, the other enables it for your chosen players. Forget the enable step and every player sees the famous You cannot trigger this objective error.
There is no target argument anywhere in the command: /trigger always acts on the player who runs it, which is exactly why it is safe for non-op players. The syntax is identical in every modern Java version, so the same generated command works from old releases to the current one.
A working trigger system is a four-step loop. The generator above produces the commands for steps 1 to 3; step 4 is your detection logic:
1. Create the objective once, as an operator: /scoreboard objectives add home trigger. The criterion must be trigger; a dummy objective will not work with /trigger at all.
2. Enable it for your players: /scoreboard players enable @a home. Triggers start disabled, and each use disables them again, so put this on a repeating command block or in a tick function to keep the trigger permanently available.
3. Players run the command from chat: /trigger home, or a value form like /trigger vote set 3. No op, no cheats, the score just changes.
4. Detect and react: select players whose score changed, run your real commands, then reset the score to 0 so the trigger can fire again. With the enable command from step 2 still repeating, the loop is complete.
This pattern powers most vanilla server conveniences: homes, TPA requests, warps, vote menus, shop pages and minigame join buttons are all trigger objectives with different detection commands behind them.
Copy any of these as a starting point, or rebuild them in the generator above:
/scoreboard objectives add home triggerOperator setup: creates a trigger objective named home. Run once./scoreboard players enable @a homeOperator setup: lets every online player use /trigger home once. Repeat after each use, usually on a repeating command block./trigger homeWhat a player types in chat. Adds 1 to their home score, no op needed./trigger vote set 3Records a vote for option 3 by writing the score directly./execute as @a[scores={home=1..}] at @s run teleport @s 0 100 0Detection: teleports every player whose home trigger has fired. Set the score back to 0 and re-enable afterwards./trigger changes the score of the player who runs it in a scoreboard objective that uses the trigger criterion. /trigger <objective> on its own adds 1, /trigger <objective> add <value> adds the value, and /trigger <objective> set <value> overwrites the score. It is the only scoreboard command regular players can run themselves, which is why servers and maps use it for chat-driven systems like /trigger home or /trigger tpa.
Either the objective is not enabled for you right now, or it does not use the trigger criterion. Triggers start disabled and every use disables them again, so an operator or a command block has to run /scoreboard players enable <player> <objective> before each use. Most setups put that enable command on a repeating command block so the trigger is always ready.
/trigger is the vanilla answer. It runs at permission level 0, so any player can type it in chat with cheats off. An operator creates an objective with the trigger criterion, enables it for players, and detects score changes with execute or a datapack function that then runs the real op-level commands. The player only ever types the harmless /trigger line.
add changes the player's score relative to its current value, so /trigger menu add 1 moves a selection one step forward and negative values move it back. set replaces the score outright, so /trigger vote set 3 always records option 3 no matter what the score was before. Plain /trigger with no mode behaves exactly like add 1.
Check the score with a selector, for example /execute as @a[scores={home=1..}] at @s run teleport @s 0 100 0. After reacting, set the score back to 0 with /scoreboard players set @s home 0 and enable the objective again so it can be used next time. Run that loop on a repeating command block chain or in a datapack tick function and the trigger feels instant to the player.
No. The trigger criterion and the /trigger command are Java Edition features. Bedrock's scoreboard has no trigger objectives, so commands built on this page are for Java only. The closest Bedrock equivalents are NPC dialogue buttons or command blocks listening for other conditions.
Build the objectives and detection side, or browse more Minecraft tools: