A TradingView sell alert can describe closing a long, opening a short or the selling needed to reverse from long to short. The word “sell” alone does not tell you which outcome the strategy intends. Before automating it, establish the intended position after the event and how the receiving setup will act on the broker account.
This matters because an exit and an entry can share the same transaction direction. Selling an existing long reduces exposure; selling to establish a short creates exposure in the opposite direction. A connector needs an instruction that preserves that distinction.
Sell describes a side; close and reverse describe an outcome
TradingView distinguishes script-generated alert events from strategy order-fill events. An order-fill alert occurs when its broker emulator fills a simulated order. That order can be an entry or an exit, so its buy or sell action is not a complete description of the strategy's intent. See TradingView's alerts FAQ.
Start with a sentence describing the desired change. The following are conceptual scenarios, not commands or tested trading examples:
| Starting position | Intended event | Desired position afterwards | What “sell” leaves unresolved |
|---|---|---|---|
| Long | Close the entire long | Flat | Whether the instruction closes existing exposure or requests a new short. |
| Flat | Open a short | Short | How much new exposure to establish. |
| Long | Reverse into a short | Short, with the previous long closed | How the close and replacement entry are handled. |
| Long | Reduce part of the long | A smaller long | How much to close and which holding the reduction targets. |
These are different instructions even though each involves selling. “Whenever the strategy sells, open a short” is only a suitable interpretation if every relevant event actually represents a fresh short entry.
A reversal is more than an opposite label
TradingView documents that its strategy entry function can reverse an existing simulated position. The resulting transaction can include the quantity needed to close the old position as well as establish the new one. That is behaviour of the strategy's broker emulator, described in the TradingView strategies documentation.
It does not establish what a separate MT5 account will do when it receives an alert. The receiving instruction, account type, existing positions and execution settings still matter. Nor should the emulator's transaction quantity be treated automatically as the desired new broker position size.
Suppose the strategy intends to finish short after being long. A useful specification says: “Close the intended long exposure, then establish the intended short exposure, and verify both results.” It also needs a rule for a failed close. Opening the replacement entry while the old exposure remains could produce a different account state from the one the strategy assumes.
For the Pine Script distinctions behind entries and exits, see strategy.entry, exit, close and order. That function reference answers how a strategy expresses orders; the automation question is what each emitted event should mean at the receiving account.
Check the broker's starting position separately
The source strategy and broker account need not be in the same state. TradingView's broker emulator simulates orders; its fills are not confirmations of fills at your broker. That separation is explicit in the strategies documentation.
For example, the emulator might still show a long after a broker-side stop has closed the actual position. A later simulated sell exit then arrives at an account that is already flat. If you interpret that event as a fresh short entry, the automation creates exposure where the strategy intended to remove it.
The opposite mismatch is possible too: a strategy can consider its long closed while the broker account still holds it. A later short-entry event must not be interpreted using the simulated position as proof of the broker's starting state.
MT5 account type also affects how opposite trading operations relate to existing positions. Use the separate netting versus hedging explanation for that account-level distinction. Neither account type makes an ambiguous alert message self-explanatory.
Write the meaning before choosing the message
For each event the strategy can produce, record four things:
- Source event: Is this an entry, full exit, partial exit or reversal? If the script is locked, obtain that meaning from its author or documented alert interface.
- Intended scope: Which account, instrument and existing position or positions should it affect?
- Desired result: Should the account finish flat, remain partly long or become short? Specify size separately from direction.
- Mismatch response: What happens if the broker is already flat, holds an unexpected position or does not complete the requested close?
Then choose the supported receiving instruction using the current PineConnector documentation. This article deliberately provides no command mapping: a word substitution cannot establish position scope or reversal behaviour.
Verify the relevant cases on an isolated demo setup by comparing the actual alert message with broker orders, deals and remaining positions. If an outcome is uncertain, inspect it before sending another instruction.
An unexpected short after an intended exit is first a question of action meaning. Additional unexplained orders are a separate investigation covered in why duplicate orders happen. Establish what one event should do before investigating why it may have happened more than once.
