Understand requests held for review
Know why a request pauses and what to do before retrying it.
Supported requests follow your permissions
Project members use the connections enabled for their project without a separate connection grant. Viewers follow results and download shared files. Contributors ask questions and prepare changes. Managers also approve changes. Chat modes, connection approval rules and the business tool’s own access limits still apply.
The chat mode controls execution, while your project role controls what you can do. Read only prevents business-tool changes. Ask for approval requires a Manager’s decision. Automatic permits supported changes for Contributors and Managers unless an approval rule requires review. Choosing a mode never changes project access.
When a request is held
For your safety, Steward only sends request types that have been reviewed. When it needs one that hasn’t been reviewed yet, such as a special business action or deleting a kind of record, it holds the request and shows a We’re still building this card. Nothing is sent to your business tool, and switching to Automatic mode doesn’t release it.
You don’t need to do anything. The request type goes on the Steward team’s review list. The team reviews it and switches it on once it’s safe. Ask Steward to continue another way in the meantime, or retry the request later. Other supported requests keep working while it’s being reviewed.
If Steward says a request isn’t supported, it usually tries a documented alternative on its own, for example by filtering records it has already fetched. If a task keeps failing, contact support with the chat link. Don’t share connection credentials.
A held request is different from an approval waiting for your decision. Approving a proposal authorizes that exact batch of changes; it doesn’t expand your connection permissions or release a request type that hasn’t been reviewed.
Check completed items before retrying
A batch can complete some items before a later item stops. Check its per-item results before retrying so that earlier changes are not repeated. Prepared changes are checked against current access again before execution; if access or rules changed after preparation, ask Steward to prepare a fresh proposal.