A strategy may identify something it wants to do and still be unable to do it. Permission is one reason. For Live activity, TraderLobby uses an authorized exchange connection to request supported actions. That connection is a controlled route to your exchange account. It is not a transfer of ownership of your funds, and it is not an unlimited instruction to act however the app chooses.

Return to API Connections and inspect the selected connection without editing it. Confirm the exchange, the account context shown, and the available connection or order-permission status. Being able to read a balance does not by itself establish that an order can be submitted. A connection can answer one kind of request while another kind is unavailable or rejected. Read the relevant status rather than treating Connected as an answer to every permission question.

Permissions exist at more than one level. Your app role affects which controls you can use. Your access to a strategy affects whether that offering is available to you. The exchange connection affects which account actions are permitted. The current trading context and its controls can also restrict activity. These checks work together. Passing one does not skip the others, and purchasing access does not repair a connection problem.

The account and connection deserve special attention when you have more than one. Two connections can belong to the same exchange and still refer to different account contexts. A strategy result from one context is not proof that another connection is ready. Before interpreting a blocked action, confirm that you are inspecting the connection associated with the strategy or position in question. Matching the coin symbol alone is not enough.

Permission also does not guarantee acceptance. The exchange may apply order-size rules, available-balance checks, market availability, or other restrictions. A request that was allowed to leave the app can still fail to complete as intended. Keep the steps separate in your mind: allowed to request, request received, and action completed. The result must be inspected after the request, not assumed from the permission screen beforehand.

For example, imagine that a strategy is enabled and its subscription is active, but the selected connection cannot place orders. Increasing its allocation would not answer that problem. The useful next step is to read the connection's status and the specific message associated with the failure. Likewise, if a control is unavailable because of your role, changing a strategy setting is not a substitute for the right access.

Your checkpoint is a short explanation: This strategy has access, it belongs to this context, and these are the permissions I can currently verify. Leave credentials private while doing that. You can describe a status without showing an API key or secret. In this lesson we are learning how to inspect the boundaries. We are not changing permissions or moving into Live to test whether an order will go through.