> ## Documentation Index
> Fetch the complete documentation index at: https://docs.melonly.com/llms.txt
> Use this file to discover all available pages before exploring further.
# ER:LC Triggers
> Learn what starts each ER:LC trigger and what data it provides.
***
ER:LC Triggers start workflows when something happens in your connected ER:LC server.\
They can react to custom commands, player activity, player counts, teams, vehicles, emergencies and moderation events.
***
## Blocks
## Commands
Starts the workflow when someone uses a custom ER:LC command created for the workflow.
**Configuration**
* **Command Name**: The name of the custom ER:LC command. It must use lowercase letters and numbers with no spaces.
* **Command Options**: Optional command arguments. Each argument must have a unique name and is processed in the order shown.
* **PM after Incorrect Usage**: Sends the player an in-game private message when the command is used incorrectly.
* **Required ER:LC Permissions**: The minimum in-game permissions allowed to run the command. Available levels are Server Moderator, Server Administrator and Server Owner. Leave this blank to allow all players.
**Option Types**
* **Word**: A single word.
* **Multiple Words**: Multiple words separated by spaces. This must be the final option.
* **Player**: A player's Roblox username or ID. Partial usernames match the closest player in-game.
* **Number**: A number.
* **Boolean**: A true or false value.
* **Channel**: A Discord channel name or ID. Partial names match the closest channel.
* **Discord Role**: A Discord role name or ID. Partial names match the closest role.
**Output**
* **Command Name**: The configured custom command name, without the command prefix or arguments.
* **Invoking Player**: The player who ran the command. This output includes ID, username, permissions, team, callsign, stars, in-game status, avatar and display name.
* **Invoking User**: The linked Melonly and Discord identity of the player. This output includes Melonly ID, Discord ID, name, avatar, Discord roles, Melonly roles, Melonly server status, nickname, join date and Discord status.
* Any custom arguments configured for the trigger. Player arguments expose the same Player properties as Invoking Player.
**Use it when**
* You want players or staff to start a workflow from the ER:LC server.
* The workflow needs to know who used the command.
This trigger needs the ER:LC event webhook. See [Event Webhook Setup](/Dashboard/erlcintegration/webhook/eventwebhook).
Starts the workflow whenever any ER:LC command is used, including native ER:LC commands and remote server management commands triggered through Melonly.
**Output**
* **Player**: The ER:LC player who used the command.
* **User**: The Melonly user connected to the player.
* **Command**: The full raw command string, including its prefix and arguments, for example `:weather clear`.
**Use it when**
* A workflow should log or react to commands used in-game.
Starts the workflow specifically when `:kick all` is used.
**Output**
* **Player**: The ER:LC player who used the command.
* **User**: The Melonly user connected to the player.
* **Command**: The command that was used.
**Use it when**
* A workflow should record or respond to a server-wide kick command.
Starts the workflow specifically when `:ban all` is used.
**Output**
* **Player**: The ER:LC player who used the command.
* **User**: The Melonly user connected to the player.
* **Command**: The command that was used.
**Use it when**
* A workflow should record or respond to a server-wide ban command.
## Players
Starts the workflow when a player joins the connected ER:LC server.
This also runs for the first player who joins and starts the server.
**Output**
* **Player**: The player who joined.
* **User**: The Melonly user connected to the player.
**Use it when**
* A workflow should run when someone joins the ER:LC server.
Starts the workflow when a player leaves the connected ER:LC server.
This runs when players leave normally or are removed, but not when the server is suddenly shut down with a command such as `:shutdown`.
**Output**
* **Player**: The player who left.
* **User**: The Melonly user connected to the player.
**Use it when**
* A workflow should run when someone leaves the ER:LC server.
Starts the workflow when a player is killed in-game.
This covers all ER:LC deaths, not only firearm kills. For environmental deaths, Killer and Killer User may be empty.
**Output**
* **Killer**: The player who caused the kill. This is a full Player object when available.
* **Killer User**: The Melonly user connected to the killer.
* **Killed**: The player who was killed. This is a full Player object.
* **Killed User**: The Melonly user connected to the killed player.
**Use it when**
* A workflow should log or react to player kills.
Starts the workflow when Melonly's internal detection system identifies a deceptive or disruptive username as a player joins. Detection rules are not configurable or publicly listed.
**Output**
* **Player**: The player whose username was detected.
* **User**: The Melonly user connected to the player.
* **Username**: The player's username as a string.
**Use it when**
* A workflow should alert staff or take another action when a troll username is detected.
## Player Counts
Starts the workflow when the server player count reaches a configured number.
The configured value can be from `1` to `50`. The trigger runs once when the count reaches the value and can run again after the count moves away and later reaches it again.
**Output**
* **Player Count**: The current server player count.
**Use it when**
* A workflow should run at an exact player count.
Starts the workflow when the server player count rises above a configured number.
For example, a threshold of `10` triggers when the count rises to `11`. It runs once when the threshold is crossed and can run again after the count drops back and later crosses it again.
**Output**
* **Player Count**: The current server player count.
**Use it when**
* A workflow should run when the server becomes busier than a set threshold.
Starts the workflow when the server player count drops below a configured number.
For example, a threshold of `10` triggers when the count drops to `9`. It runs once when the threshold is crossed and can run again after the count rises back and later crosses it again.
**Output**
* **Player Count**: The current server player count.
**Use it when**
* A workflow should run when the server falls below a set threshold.
Starts the workflow when any team's player count reaches a configured number. The Team output identifies which team reached it.
The trigger can run again if that team's count moves away from the configured value and later reaches it again.
**Output**
* **Team**: The ER:LC team being counted.
* **Player Count**: The number of players on that team.
**Use it when**
* A workflow should run when a team reaches a specific size.
## Teams & Callsigns
Starts the workflow when a player joins an ER:LC team after initially spawning as a Civilian. The initial Civilian assignment does not trigger it.
**Output**
* **Player**: The player who joined the team.
* **User**: The Melonly user connected to the player.
* **Team**: The team the player joined as a string.
* **Callsign**: The player's callsign as a string.
* **Previous Team**: The player's previous team as a string.
**Use it when**
* A workflow should react to a player changing teams.
Starts the workflow when a player joins a team using a callsign. Callsign availability and reuse are controlled by ER:LC.
**Output**
* **Player**: The player using the callsign.
* **User**: The Melonly user connected to the player.
* **Callsign**: The callsign being used as a string.
* **Team**: The player's current team as a string.
**Use it when**
* A workflow should validate, log or react to callsign usage.
## Vehicles
Starts the workflow when a player spawns a vehicle for themselves. It does not trigger when someone enters, drives or rides as a passenger in an existing vehicle.
**Output**
* **Player**: The player using the vehicle.
* **User**: The Melonly user connected to the player.
* **Vehicle Name**: The name of the vehicle.
* **Plate**: The vehicle's plate as a string.
* **Livery**: The vehicle's livery as a string.
* **Color**: The vehicle color as a hexadecimal color string.
**Use it when**
* A workflow should log or react to vehicle usage.
Starts the workflow when a player spawns a vehicle using a livery that exactly matches the configured string. Matching is case-sensitive.
**Output**
* **Player**: The player using the vehicle.
* **User**: The Melonly user connected to the player.
* **Vehicle Name**: The name of the vehicle.
* **Plate**: The vehicle's plate.
* **Livery**: The vehicle's livery.
* **Color**: The vehicle's color.
**Use it when**
* A workflow should react to an exact livery or plate match.
* For broader checks, use workflow conditions after the trigger. See [Conditions](/Dashboard/resources/workflows/conditions).
Starts the workflow when a player spawns a vehicle using a plate that exactly matches the configured string. Matching is case-sensitive.
**Output**
* **Player**: The player using the vehicle.
* **User**: The Melonly user connected to the player.
* **Vehicle Name**: The name of the vehicle.
* **Plate**: The vehicle's plate.
* **Livery**: The vehicle's livery.
* **Color**: The vehicle's color.
**Use it when**
* A workflow should react to an exact livery or plate match.
* For broader checks, use workflow conditions after the trigger. See [Conditions](/Dashboard/resources/workflows/conditions).
## Emergencies & Modcalls
Starts the workflow when an emergency call is created in-game.
This covers all emergency calls created in-game and requires the ER:LC event webhook to be configured.
**Output**
* **Team**: The team associated with the emergency as a string.
* **Description**: The emergency description as a string.
* **Call Number**: The emergency call number as a number.
* **Location**: The named ER:LC location as a string.
* **Caller**: The player who created the emergency.
* **Caller User**: The Melonly user connected to the caller.
**Use it when**
* A workflow should log, forward or react to new emergency calls.
This trigger needs the ER:LC event webhook. See [Event Webhook Setup](/Dashboard/erlcintegration/webhook/eventwebhook).
Starts the workflow as soon as a moderator claims a modcall in-game.
**Output**
* **Caller**: The player who created the modcall. This is a full Player object.
* **Caller User**: The linked Melonly user, when available.
* **Moderator**: The player who claimed the modcall. This is a full Player object.
* **Moderator User**: The linked Melonly user, when available.
**Use it when**
* A workflow should record who answered a modcall.
Starts the workflow when the number of unanswered modcalls reaches a configured number.
It behaves like Player Count Reaches: it runs once when the exact configured count is reached and can run again after the count moves away and later reaches it again.
**Output**
* **Modcall Count**: The current number of unanswered modcalls.
**Use it when**
* A workflow should alert staff when too many modcalls remain unanswered.
## Moderation
Starts the workflow when a player is kicked through any ER:LC moderation action, including remote server management and Melonly-triggered commands.
**Output**
* **Player**: The player who was kicked.
* **User**: The Melonly user connected to the kicked player.
* **Moderator Player**: The player who issued the kick, when it came from an in-game moderator. This may be empty for remote server management actions.
* **Moderator User**: The Melonly user connected to the moderator, when available. This may be empty for remote server management actions.
* **Reason**: The kick reason as a string, when one is available.
**Use it when**
* A workflow should log or react to an in-game kick.
Starts the workflow when a player is banned through any ER:LC moderation action, including remote server management and Melonly-triggered commands.
**Output**
* **Player**: The player who was banned.
* **User**: The Melonly user connected to the banned player.
* **Moderator Player**: The player who issued the ban, when it came from an in-game moderator. This may be empty for remote server management actions.
* **Moderator User**: The Melonly user connected to the moderator, when available. This may be empty for remote server management actions.
**Use it when**
* A workflow should log or react to an in-game ban.
***
## Working With ER:LC Triggers
ER:LC triggers use events from the connected ER:LC server. The server must be active and have at least one player connected for ER:LC workflow data to be available.
When using ER:LC triggers, keep in mind:
* Outputs: Connect values such as Player, User, Team, Command, Vehicle Name or Reason to later blocks.
* Player and User: Player outputs contain ER:LC player data. User outputs contain the linked Melonly and Discord identity and may be empty when no linked user is available.
* Threshold Triggers: Reaches triggers run at the exact configured value. Rises Above and Drops Below run when their threshold is crossed.
Custom ER:LC Command and Emergency Created require the ER:LC event webhook. See [Event Webhook Setup](/Dashboard/erlcintegration/webhook/eventwebhook).
### Example Workflow Flow
1. The number of unanswered modcalls reaches `3`.
2. The workflow reads the current modcall count from the trigger.
3. The workflow sends a message in the staff channel saying `3 modcalls are waiting.`
4. The workflow sends an in-game message asking available staff to answer modcalls.
***
Still have questions? Join our Discord server for support from the Melonly Team.
This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.