Make the client's live decision precise
Approve Google Ads changes for consultants: review the exact target, action and execution outcome
Keep consulting advice separate from live authority. Prepare supported account changes with readable steps, connected-owner confirmation, current-setting checks and an honest result that distinguishes verified execution from later business performance.
Establish the evidence for a recommendation
Describe the observation that motivates the edit. A campaign's selected-period performance, a current status or a reported destination topic can support a decision, but each has its own evidential boundary. A low return ratio does not establish a broken website. An enabled status does not prove recent delivery.
Name the metric and period when performance drives the recommendation. Total primary value differs from purchase-only value, and a lead population differs from all primary conversions. The client should understand which result made the campaign a candidate for attention before reviewing a pause or budget change.
Check coverage before proposing a broad action. A capped preview is not a complete candidate list. Unread campaigns cannot be ranked confidently against successfully retrieved campaigns. If the intended selection depends on unavailable evidence, resolve that dependency or narrow the conclusion rather than preparing an arbitrary subset.
Bring business context into the decision without manufacturing account facts. Availability, margins, service capacity and promotional plans can change whether an edit is appropriate. The consultant can ask the client for these inputs and explain their relevance. The performance tool should not invent them from a campaign name.
A clear recommendation can therefore have three parts: the observed state, the business reason for considering a change and the exact operation to review. These parts need not create a long message. Their separation makes the proposal easier to assess and leaves a useful record if the client declines it.
Choose a supported operation
The framework uses declared edit capabilities and dependency rules. A readable setting is not automatically writable, and a writable provider field does not automatically make every possible operation available through the current application. Select the actual supported action and its valid target before promising a live outcome.
Capability discovery can happen locally. The AI can inspect which actions and entity relationships are available without scanning the client's whole account. Preparation then obtains the live values and prerequisites needed for the selected action. This keeps discovery efficient while preserving factual target resolution.
When a request is unsupported, explain the precise boundary and the next usable step. A missing required input can be obtained from the client. An incompatible campaign type needs a compatible target or operation. A provider-only field without an implemented write path needs a different workflow. These are different problems, not a generic claim that edits are impossible.
Keep account edits distinct from website and business tasks. A destination problem may require website repair rather than a URL-field replacement. A conversion issue may require implementation work or a business measurement decision. The supported operation should follow the actual problem, not merely the closest available button.
Resolve the target and actual parents
A campaign proposal names the campaign. A keyword proposal names the keyword, its ad group and campaign. A PMax product targeting occurrence needs the asset group and campaign, while Standard Shopping uses the relevant ad group. These relationships give the client enough context to recognise the intended resource.
Internal resource identity keeps the exact target stable behind the scenes. The client-facing proposal should use meaningful names and actual parent labels instead of exposing raw asset IDs or displaying an undefined parent. An ad group does not become another ad group's parent because a generic formatter reused a field incorrectly.
Handle duplicate names before preparation. If two campaigns contain an ad group called Starter Range, ask which parent campaign the client means when the thread cannot resolve it. If the conversation has just identified one exact group, use that established context rather than asking the client to repeat the selection unnecessarily.
Current target resolution matters even when a prior conversation provides the name. An asset may have changed, been removed or moved outside the supported state. The proposal should retain the exact selected resource and relevant preparation evidence. Remembering a name is helpful context, not proof that a live operation remains valid.
State the intended change plainly
Use direct action language: pause the selected campaign, enable the selected ad group, set the daily budget to the chosen amount or add the listed keywords with their selected match type. A user should not need to interpret a raw operation object to discover what will happen.
For an existing setting, show the relevant before-and-after values when available. State the monetary unit for budgets and the intended status for creation or enablement. Avoid ambiguous wording that appears to create a parent campaign when the actual operation creates a child ad group in an existing campaign.
For creation, distinguish the new resource from existing parents. A new ad group in an existing campaign is one creation context; a new campaign with a new group is another. A status such as paused belongs to the named resource. Write each step so the client can tell exactly which resource receives that status.
Removal also needs precise language. Removing an asset, detaching a relationship and pausing delivery are different actions. Do not call all three deletion. The proposal must describe the supported operation and its scope so the client can judge the intended consequence before confirming.
Keep the business rationale concise beside the action. The rationale can explain why the consultant recommends the change, while the operation describes what Google Ads will receive. Neither should obscure the other in a dense paragraph of technical terminology.
Show each logical step separately
A request can contain several logical actions, such as adding keywords and enabling their existing group. Show each action in its own readable section. One confirmation can cover the supported prepared request, but the client still needs to see every requested change rather than infer a later action from the first step.
Repeated items under one action belong together. Several keyword additions can be listed under Add keywords, with their match type and intended status clear. Enabling the group remains a distinct step. This prevents a result that successfully adds the words but silently omits the requested enablement.
When the request is too large for safe review, ask the client to split it into smaller requests. The client-facing message explains that there are too many changes to make or review at once. It need not expose internal numerical limits or count the framework's action kinds as though they were a product feature.
Do not prepare an undisclosed partial request. If the supported batch cannot represent a required action or dependency, resolve it before creating the approval. A concise refusal with the exact missing requirement is preferable to a proposal that looks complete while implementing only its easiest portion.
Plan parent and child dependencies
A new child resource needs the appropriate parent. The local dependency graph validates the supported entity relationship and orders producers before consumers. This applies according to the declared action and channel rules, rather than an assumption that every creation chain is a Search campaign example.
The planner rejects contradictory or invalid dependencies before performing the required provider preparation. A child cannot refer to itself as its parent. A reference must produce the expected entity type, and the selected channel must support the requested child operation. Creating and immediately removing the same new asset is not a useful implicit workflow.
Google's mutation overview describes several write mechanisms, including supported linked operations. A consultant should not infer that every application request uses the same mechanism or has the same all-or-nothing guarantee.
The framework's dedicated-service rules and preparation constraints remain relevant. Some operations cannot join a general multi-action proposal. Some references are valid only for existing resources. Local dependency ordering provides a coherent plan, but it does not promise universal atomicity across separate services or every accepted API setting.
Present the resulting sequence in business-readable steps. The client needs to see the new parent, the child placed under it and the selected initial states. Temporary internal references are implementation details; they should not replace names or leak into the approval message.
Control shared and account-wide effects
Some actions affect one asset, while others affect a shared relationship or the account. Determine that scope before preparing the proposal. An account-level app-category exclusion does not need campaign discovery merely to find an arbitrary target. A campaign-specific edit must not be broadened into an account-wide operation for convenience.
Shared resources can affect more than one apparent target. A shared negative list needs its attachment context, and an attached asset can have several relationships. Creating an empty list and attaching it to a campaign are different operations. The proposal should not claim that creation alone changes campaign exclusions.
A selected keyword or product occurrence has parent-level context. If the same product is excluded in several enabled groups, an inclusion request must identify the intended occurrences. Enabling it in one group does not establish that all campaign occurrences are included. Preserve the complete requested selection.
Explain breadth in ordinary language. The client should understand whether the change affects this campaign, the listed groups or the account. Raw identifiers and API names do not substitute for that explanation. The consultant's responsibility is to make the consequence visible before the owner confirms.
Review complete creative inputs
Creating an ad needs the complete required creative and destination context. A discussion of headline ideas is not a live creation request, and a partially remembered ad draft is not enough to prepare a valid write. Obtain the supported required inputs and show the target group clearly.
For a responsive search ad replacement, review the complete headline and description set, final URLs and relevant paths or pinning choices. A small requested wording change can affect a larger stored creative representation. The proposal should make the resulting creative understandable rather than presenting an isolated fragment as the entire update.
A bare domain can be normalised to a syntactically suitable HTTPS URL where the supported input path does so. That normalisation does not test the destination's reachability, product fit or customer journey. Website validation remains a separate observation when the business decision needs it.
New creative can begin paused under the supported creation behaviour. State that initial status explicitly. A successful creation does not establish provider approval or delivery. If enablement is also requested and supported, it belongs to the prepared action sequence rather than an assumed invisible follow-up.
Separate business allowances and live budgets
A client's monthly allowance and a campaign's live budget setting serve different purposes. Tracking the allowance can support a pacing decision, but it does not itself change the campaign budget or enforce an account-wide spending cap. State which value the proposed operation actually edits.
The convenience daily-budget path has eligibility constraints, including an enabled campaign with a non-shared daily budget referenced by one campaign. Those constraints prevent a seemingly narrow operation from changing a shared budget unexpectedly. Do not imply that every campaign budget fits that exact path.
Use the current selected value and account currency in the proposal. A reference derived from a remaining allowance is a planning input; the owner decides whether to apply a supported live setting. Forecasted spend does not guarantee the resulting bill or future campaign delivery.
A return or cost target also needs the existing supported bidding context. A target value should not be prepared by guessing that every strategy exposes the same setting. Inspect the eligible current state and select the actual operation. The consultant can explain the intended business tradeoff without promising a future performance result.
Preserve complete filtered selections
A request to edit all matching assets requires a complete selection. The framework can carry exact edit-selection information from a related dataset, with the appropriate group keys and item selections. It should not copy a short visible preview into a live operation and call it the whole result.
Performance conditions require sufficient evidence. Products with unavailable return history do not satisfy a known greater-than-three condition. Negating that condition does not make unknown history a known low return. Preserve filter coverage so the owner understands what was actually selected.
When the complete selection exceeds the review boundary, ask for a narrower campaign, group or condition. A partial display can still help the client choose a scope, but it is not permission to edit only the first displayed items. The prepared proposal must match the disclosed population.
Retain current and historical contexts separately. A product's current exclusion and a historical performance observation can identify a candidate, while the live preparation checks the current target before mutation. The approval does not assert that the product held the same state throughout the historical period.
Follow an invented approval case
Consider an invented client, Willow Bank Workshops. Its consultant has identified the existing campaign Weekend Courses and the paused group Introduction Sessions. The client asks to add several exact-match course keywords to that group and then enable the group. This is an illustrative workflow, not a customer account or performance claim.
The proposal names the existing group and its parent campaign. One step lists the selected keywords with exact match and their intended status. A separate step states that Introduction Sessions will change from paused to enabled. The campaign is an existing parent, so the wording does not imply that a new campaign will be created.
The client can review whether the keyword phrases fit the actual course and whether the offer is ready. The consultant can explain the rationale without treating that explanation as permission. Only the connected owner's confirmation starts the live execution workflow for the prepared request.
Suppose another authorised account change enables the group before this proposal executes. The relevant stored preparation no longer matches current state. The stale proposal should not be applied unchanged. Obtain a fresh proposal that reflects what still needs to happen, rather than repeating an already completed step under an old decision.
When a valid proposal completes, the result identifies the executed steps and their checked outcomes. The consultant then plans a later performance observation. Added keywords and an enabled group establish configuration; they do not prove traffic, course bookings or the quality of incoming enquiries.
Prepare the proposal in Slack
The client can request a supported edit in ordinary language. The AI resolves the action, account and targets, obtains the required current inputs and prepares a proposal. No live mutation should occur merely because the model has recognised the requested action.
Readable sections make the proposal reviewable. Lead with the target and meaningful parent context, followed by the actual steps. Status belongs to the resource being changed. A keyword list should be visually grouped under its addition step rather than mixed into a sentence that obscures group enablement or campaign creation.
Keep internal references out of normal client prose. Exact identity remains essential to the prepared payload, but the user sees names and relevant relationships. If a product identifier is itself the selected business item, it can be included as product context; that differs from exposing internal account references unnecessarily.
The pending message states: No changes have been made yet. This proposal expires in 15 minutes. The confirmation control follows the reviewable content. It should be clear that the client is approving the displayed operation, not granting indefinite permission for future edits discussed in the thread.
Use the connected-owner confirmation
For a client meeting, make the review sequence practical. The consultant can explain the recommendation while the owner checks the displayed target, parent and values. If the owner requests a different value during that discussion, prepare the revised proposal rather than asking them to confirm the old message and relying on an unrecorded verbal correction. The live instruction must remain the same as the decision shown for approval.
Where a new account operator joins the engagement, review the connection and installation context before assigning confirmation responsibilities. A person's general business authority does not automatically update the application's stored authorisation relationship. The supported connection workflow establishes that relationship; the confirmation flow checks it. Keeping those tasks distinct prevents an administrative transition from being mistaken for an ordinary edit approval.
The confirmation is checked against the stored proposal and its linked Slack message. Team, channel, message and actor context matter. A copied button payload or a click from an unrelated conversation should not become a valid instruction for another account.
The owner and installation checks run before the proposal advances. The account connection must still match the prepared scope, and the confirming user must match the expected installation actor. This preserves the authorised path even when a shared channel contains several people discussing the recommendation.
The workflow advances a pending proposal through controlled state transitions. Repeated clicks on an already approved or executing proposal do not create another independent mutation. The client should wait for the existing request's result instead of interpreting a delayed message as a reason to submit the same operation again.
A cancellation request has its own transition. When a still-pending proposal is cancelled successfully, the result states that no account changes were made. An executing request is a different state and should not be casually treated as cancellable pending work. Use the recorded outcome to decide the next step.
Handle expiry and replacement proposals
A pending proposal has a fifteen-minute review window. Once expired, it cannot be used as a current permission to edit. The client can ask for a fresh proposal, which retrieves or validates the relevant preparation again. Expiry prevents an old decision from being applied much later without review.
A replacement proposal supersedes earlier pending proposals in the same scoped conversation. This is useful when the client changes the requested value or target. The latest reviewable proposal should represent the actual intended request, while the older one should not remain a competing live control.
Do not equate an old message remaining visible with an active proposal. Stored state determines whether the control can execute. The workflow can publish an unavailable or expired outcome when the client interacts with an obsolete message. The consultant should direct the client to the fresh decision rather than asking them to keep clicking the old button.
Expiry is distinct from current-setting staleness. A proposal can still be within its review window but no longer match the selected account state. It can also expire without any account change. Both require a fresh proposal, but the explanation should identify the actual reason.
Check current relevant settings
Preparation records the state relevant to the intended operation. Execution checks that state again under the account's write coordination. A consultant or another account operator may have changed the target after preparation. The supported current-state check prevents an old plan from overwriting a newly changed relevant setting.
The check is deliberately related to the prepared operation. It does not require rereading every field in the account. A narrow pause operation and a complete creative replacement have different evidence requirements. The framework should retain the prerequisites needed for each selected action rather than perform an unrelated broad scan.
If the state changed, the stale result explains that no edit was executed by this proposal and asks for a fresh preparation. That result is useful protection, not proof that the original recommendation was wrong. The consultant can inspect the new state and determine which actions remain appropriate.
Account coordination reduces conflicting app writes, but it does not replace the owner's review or guarantee that every external operator will preserve the state. Current checks and exact write scope still matter. Explain the workflow's actual safeguard without promising universal control over the account.
Understand preflight validation
Validation asks whether the proposed supported request is acceptable before live mutation. Where the API path supports preview validation, the executor uses that path. A rejected preview stops the live write and reports that no changes were made by the rejected proposal.
Some API methods do not support the same preview mechanism. The executor uses declared support rather than inventing a universal dry run. The consultant should not claim that every operation passed an identical provider preview merely because the application has a validation stage.
Validation and verification answer different questions. Validation checks the proposed operation before sending a live mutation. Verification checks the recorded result after the mutation, using receipts and supported readback. Passing one cannot prove the other, and neither alone proves a later business outcome.
A valid request can still encounter a provider failure or an uncertain response during execution. Preserve the actual state and dispatch evidence. A reassuring validation message should never be used to hide a later partial or unverified outcome.
Show visible progress after confirmation
After the owner confirms, the original pending message updates to a prominent change-in-progress status. The pending action controls are removed, and the displayed steps remain available for reference. This gives the client immediate feedback that the click reached the workflow.
The progress wording describes checking and applying the approved edit; it does not claim completion. It should be visually distinct enough to notice without requiring the client to inspect a small line of text. The progress status does not add a user mention, keeping the update focused on the work.
The final result replaces that status when the workflow records its outcome. A separate completion receipt can appear in the thread as well. Those two message surfaces describe the same execution; they are not evidence that the mutation ran twice.
If the status remains in progress unusually long, reconcile the stored request and account state before repeating the edit. A delayed UI update can have different causes from a delayed provider write. The consultant should not infer that nothing happened merely because the final message has not appeared.
Read the execution outcome
The prominent executed-and-verified result indicates that the supported operation and its verification completed. It includes the relevant readable changes, so the client can relate the outcome to the approved steps. This is stronger evidence than a conversational statement that the AI intended to make the change.
An accepted request has a different meaning. Some paths use acknowledgement mode, where Google accepted the approved request but final completion has not been independently verified. The outcome should preserve that limitation. A returned acknowledgement should not be relabelled as a checked final account state.
An execution-not-fully-verified outcome means the edit was sent but the complete result could not be established. Some changes may have applied. This does not prove the entire request failed, and it does not justify blindly submitting it again. The account requires reconciliation before another related write.
A rejected or stale pre-dispatch outcome can state that the proposal made no live change when the evidence supports that conclusion. Keep it separate from an interrupted dispatched request. The user should be able to tell whether to prepare again or first inspect what may already have happened.
Reconcile an uncertain dispatched request
Once a request may have reached Google, an interruption creates a different risk from an ordinary preparation failure. The executor records uncertainty and does not automatically replay the mutation. Creating another ad or group without checking could duplicate a resource that was already added.
Begin reconciliation with the exact approved steps and target context. Inspect the current account state using the relevant supported read. Identify which expected resources or setting values are present and which remain unresolved. A generic account scan is less useful than a focused check against the actual proposal.
Separate messaging recovery from account execution. The notification path can publish a recorded outcome but cannot dispatch a Google mutation. Reposting the status should therefore not become a hidden execution retry. If the delivery failed, restore the communication using the existing execution evidence.
If a new proposal is needed, prepare only the remaining confirmed work under current state. Do not reuse the old payload as though the interruption erased all effects. The consultant should give the owner a clear account of what is known, what is not and what the fresh proposal will change.
This discipline is especially important for multi-step requests. One step may have completed before a later result became uncertain. Keep each available receipt and checked state associated with its operation. A blanket success or blanket failure can both mislead the client's next decision.
Keep scheduled Rules distinct
A conversational proposal and an explicitly configured scheduled Rule are different workflows. The proposal waits for its specific confirmation. A Rule follows the separately selected condition, schedule and action mode. The consultant should explain which mechanism the client is configuring rather than treating a discussion as standing automation authority.
Some configured workflows can request approval when a condition is met; an automatic mode is a separate deliberate choice. A performance alert that reports a threshold crossing is also distinct from a write. Do not imply that every notification silently edits the account.
Choose the condition and observation period carefully before configuring automation. Above and at-or-above are different boundaries, and unavailable evidence is not a measured zero. The same measurement discipline used in a one-time recommendation matters when a recurring workflow depends on it.
Record who owns ongoing review. A configured Rule should not outlive its business purpose unnoticed after a consulting engagement ends. The handoff identifies the intended behaviour, the responsible owner and any future decision about retaining or changing it.
Remove duplication without skipping checks
Local action and dependency discovery avoids unnecessary provider requests. The framework can determine parent relationships, valid action kinds and unsupported combinations before reading account values. This is especially useful when the client's initial request needs clarification before any live preparation is meaningful.
Reuse an established report selection where it supplies relevant evidence. A campaign ranking can identify the target for a later pause proposal, while the live preparation still checks the required current setting. Do not reread the same performance totals solely to rewrite the recommendation.
Current-state checks, supported provider validation and result verification have distinct purposes. Removing repeated broad scans is appropriate; removing these relevant checks merely to shorten the flow would weaken the decision. The consultant should optimise the evidence path rather than equate fewer calls with safer execution.
Keep status delivery separate from provider work. A progress update does not require another account read, and publishing the completion receipt should use the recorded outcome. This preserves responsive Slack feedback without making each message another mutation or verification cycle.
Document the decision and follow-up
Record a declined recommendation with the same care as an accepted one. The client may retain a campaign because of service capacity, an upcoming launch or information the advertising report does not contain. Preserve that rationale as a business decision, not an account measurement. A later consultant can then revisit the relevant question without assuming that a visible unresolved finding was simply overlooked.
For a staged implementation, name the dependency that separates the stages. A website route may need repair before a new destination proposal is appropriate. A product may need availability confirmation before an inclusion decision. The first completed task should not automatically authorise the later account write. Prepare that later proposal with the now-current context and let the owner review its exact effect.
This record also helps distinguish a fresh recommendation from a retry. A newly prepared request after reconciliation describes known remaining work. Reusing an uncertain payload without inspection is a different action. The handoff should make the first path possible and clearly identify why the second is inappropriate.
The handoff should state the approved target, steps, execution outcome and remaining checks. Meaningful names and parents help the client understand it. Internal identifiers, raw payloads and provider error dumps belong in operational evidence rather than the ordinary client-facing account of the decision.
Distinguish account completion from website, provider-review and commercial milestones. A stored URL may be verified while a customer-journey check remains open. A new ad can be created while approval remains pending. A budget can change while its later spend effect remains unobserved.
Choose the next performance review using the actual business question. Retain the same result definition and explain any changed population. A before-and-after comparison can show movement but does not automatically prove that the approved edit caused it. The consultant should preserve the difference between chronology and causality.
Connect the decision to client reporting and account questions for later evidence, or budget tracking for its planning context. Each workflow supports a defined next question rather than a promise that every edit will improve results.
Answer common approval questions
Does the consultant's recommendation make a live change?
No. A supported conversational edit requires the prepared proposal and connected-owner confirmation.
Can anyone in the channel confirm?
No. The workflow checks the connected owner, account, installation and expected confirming actor.
Does validation mean verification?
No. Validation checks the proposed request before live mutation. Verification checks the supported result afterward.
Does an expired proposal still work?
No. Ask for a fresh preparation so the intended target and current relevant state can be reviewed again.
Does an uncertain result mean nothing changed?
No. A dispatched request may have applied. Reconcile its actual account state before another related write.
Does verified execution prove better performance?
No. It establishes the checked account result. Later performance, provider review and website behaviour are separate observations.