1. Start with a clear description of the affected service or website, the observed symptom and the desired result.
2. Let the Engineer inspect relevant information. Read-only tool requests can run without a write approval.
3. When the interface asks Ready to make this change. OK to go ahead?, use See the change to inspect the proposed operation.
4. Check the target, the data affected and whether a backup or maintenance window is required.
5. Select Go ahead only when the proposal is suitable, or Don't to decline it.
6. After execution, independently verify the result through the website or relevant hosting tool.

Run changes without asking changes the interaction for eligible actions and should be used deliberately. The Hosting Engineer still requires approval for actions classified as destructive. Classification and prompting help the workflow, but they do not replace a customer's assessment of business impact.

The available tools are constrained by the product, account integration and permissions. Application-plan tools are filtered by that plan. Do not describe the Engineer as root access or a general server administrator. Some provider operations can have broader effects than their label suggests, so review the exact action instead of assuming every hosting API operation is inherently limited to a single website.

Undo is available for specific tracked file edits and writes where the module created a recoverable snapshot. It is not universal rollback for shell commands, SQL changes, plugin actions, application updates or every hosting operation. The tracked history is limited, so an old action may no longer have a usable Undo record.

Before a significant change, create an appropriate backup and understand its restore procedure. A file snapshot cannot restore a separately changed database, email state or external service. Check what the proposed recovery would actually cover.

Stop further automatic changes and record what happened. If the exact action has Undo, review its scope and use it only when restoring that state is still appropriate. Otherwise recover using the relevant website, database or account backup procedure. Verify both the original symptom and any dependent functions.

For support escalation, include the affected service, action description, time and safe error output. Avoid copying passwords, private keys, customer records or entire sensitive configuration files into the chat.

Train staff with a disposable file containing known text. Ask the Engineer to explain it, propose a small edit, and pause for approval. Decline the first proposal, then submit and approve a clearly understood revision. Confirm the resulting file and inspect whether the exact action has an Undo record.

This exercise shows the difference between a proposal, execution and verification without placing a customer's application at risk. Repeat with a read-only hosting question to demonstrate the product's scope. Do not extend the lesson into destructive database or shell operations merely to test the classification. Use written examples to explain that a permitted action can still be inappropriate for a particular business situation.

• Connect an AI provider and enable the customer Engineers
• Troubleshoot AI access, failed requests and incomplete work
• Define and test the backup scope of managed WordPress plans
• Prepare customer Terminal access and verify SSH host identity