Give the client a recorded reason and an accountable next action
Why are my Google Ads disapproved? An agency workflow for recorded policy findings, corrections and review
Google has recorded a policy decision affecting an ad, asset or destination. Start with that decision, identify the exact account and resource, then separate supported corrections from Google's later review.
Answer from the recorded decision
An ad is disapproved because Google recorded a policy decision affecting its content, associated assets or destination. Missing traffic alone does not establish that decision. In a connected client channel, run /ppctor policy for current findings, then identify the reported topic and affected resource before choosing a correction. This gives the agency an evidence-based starting point instead of a generic list of possible reasons that leaves the client no closer to the actual issue.
The first response should say what Google reported and where it applies. A statement that the account might violate advertising policies is too vague when an actual finding is available. Equally, a confident explanation inferred from the product category is not a substitute for reading the recorded status. The agency should distinguish the provider's decision from its own investigation of why the content or destination triggered that decision.
Google's disapproval guidance directs advertisers to inspect policy details, correct applicable content or destination issues, or use an appropriate appeal route. A disapproved ad cannot run until the issue is resolved and reviewed. That establishes the broad workflow. The current account evidence determines which resource and action need attention, while the agency remains responsible for communicating what is confirmed and what still requires investigation.
Sometimes the initial assumption is wrong: the ad is paused, limited or still under review rather than disapproved. Correct that assumption directly using the recorded state. The agency should not agree with the client's diagnosis merely because the campaign stopped producing impressions. A useful answer identifies the actual condition and next check. This protects the team from rewriting content unnecessarily or promising an appeal for a problem that is actually a management setting.
Confirm the client account first
An agency can have several clients, regional accounts and Slack channels with similar campaign names. Establish the connected account before interpreting or acting on a finding. A screenshot from one account should not become an edit instruction for another. The channel connection provides context, but the assistant still needs to retain that context through the investigation. If the user changes account or channel, make the selection deliberate rather than silently carrying an old target into a new client conversation.
Use the readable account name and campaign context when useful. Internal account identifiers are operational data, not the explanation a client needs. An agency handover should make the affected business and resource recognisable without publishing owner emails or resource paths. Where names are ambiguous, ask a focused question or use meaningful parent context. Precision behind the scenes and clarity in front of the client are compatible; raw identifiers should not be the default way to locate the issue.
A manager-account relationship does not mean every person in the agency has authority to approve the app's edits. The connected ownership and execution rules still apply. A strategist can investigate and propose a correction, while the authorised owner confirms the prepared operation. Keep those responsibilities clear before a live request. A policy finding can be discussed in Slack without making every participant an executor of changes to the client's Google Ads account.
If the channel is not linked, establish the account connection before claiming current evidence. A conversation about a product can remain useful, but it does not provide access to the client's policy state. The actual deterministic command requires the account context. Explain the missing connection politely and direct the user to the supported connection flow. Do not invent a clean policy result or route the discussion into an unrelated workspace just to produce an answer.
Locate the exact affected resource
A policy issue can apply to an ad, an associated creative asset, an asset-group asset, a keyword or the account itself. Identify the resource before planning the repair. A logo finding is not the same as an RSA text finding, even if both appear under the same campaign. The agency needs the recognisable item and actual parent context so the content owner can locate it and the execution workflow can address the correct resource.
For an ad-group ad, preserve a recognisable creative description, ad group and campaign. For a Performance Max asset-group asset, preserve the asset group and campaign instead. A keyword has its own text and group context. Do not invent a parent ad group for another ad group or turn an asset group into a standard Shopping group. Correct hierarchy matters because applicable fields, associations and repair paths vary between resources and campaign families.
Two ads can have similar headlines or share a destination. Resolve the exact resource internally rather than assume the first matching text is the intended target. The user-facing confirmation can distinguish it through readable content and parents. If ambiguity remains, ask which specific item the user means. A correct diagnosis applied to the wrong ad is still a failed workflow, especially when the agency manages repeated creative across several regional campaigns.
Retain the verified target through follow-ups. What should we change in that ad should refer to the resource just discussed when the context is clear. If the client introduces another item, update the target deliberately. Good context handling reduces repeated provider reads and protects the correction from drifting to a similarly named resource. It also lets the agency move naturally from diagnosis to creative preparation without restarting the entire investigation.
Distinguish disapproval, limitation and review
Disapproved and limited have different serving consequences. A blocked policy result prevents the affected item from serving, while a limitation can restrict where or under which conditions it serves. The policy module maps returned approval states into ordinary-language effects so the reader can distinguish these outcomes. The agency should preserve that distinction instead of summarising every finding as a disapproved ad. The total can include several kinds of resources and restrictions.
Under review is also different from a final approval decision. A finding can carry the provider's review status, and the command notes when an item remains under review. Do not rewrite creative solely because the team expected an immediate result. Inspect the actual current state and submission context first. An agency can explain that review is pending without promising that the item will pass or treating the delay as proof of a permanent policy violation.
Google's ad-review explanation says that creation or editing starts review and that more complex reviews can take longer than the usual timeline. Use this as process context rather than a guarantee for the client's exact item. Repeated edits can restart review. The agency should avoid promising a precise completion time that the app cannot control, especially when the recorded state still indicates ongoing provider review.
A limited result may be expected for an offer subject to particular advertising conditions. Read the specific topic and effect before attempting to remove all limitations. The business might need a certification or an appropriate campaign scope rather than new copy. Conversely, a misleading label may warrant an appropriate review request. The recorded state gives the starting point; the agency's next action should be matched to the actual requirement, not to a generic desire for every row to look approved.
Keep management status separate
A paused ad can also be disapproved. Pausing does not resolve the policy decision, and approval does not automatically enable the resource. Keep management and policy status separate in the client explanation. If the team intends to launch the paused item later, its policy finding still matters. If the user asks only for the policy issue, do not silently enable the ad as part of the diagnosis or represent a management change as a policy repair.
The current policy ad reader includes non-removed ads in non-removed campaigns, so paused items can remain in its findings. This is useful for launch preparation, but it means the count is not restricted to ads actively trying to serve today. State the population when comparing it with an active-campaign report. A larger policy count can be expected even when the audit's active-ad disapproval count is smaller, because the two tools answer different coverage questions.
Parent status matters too. An otherwise eligible ad inside a paused campaign or group will not serve as intended. A final policy result should not be presented as a guarantee that traffic resumes if a parent still prevents it. If the agency wants to enable the full structure, resolve each requested resource and operation explicitly. Creating or approving content, enabling an ad and enabling its parent are separate effects that need clear preparation.
A removed item should not be confused with a current launch candidate. Old screenshots and emails can concern resources no longer relevant to the live plan. Establish whether the affected item still exists and what state it has now. The agency can retain historical evidence for explanation without preparing a mutation against a guessed resource. Current identity, policy state and management intention together determine the useful next action.
Understand the five policy surfaces
The current policy collector reads account, ads, ad assets, asset groups and keywords as separate surfaces. It combines their findings into one list rather than forcing the agency to interpret five unrelated output formats. These are five independent reads of the same account, run in parallel. The benefit is broader policy orientation with preserved resource meaning. It is not a promise that one finding count equals the number of unique blocked campaigns or affected customers.
An ad's own summary and an associated asset can both produce findings. Their relationship matters when identifying the repair, but the list should not be treated as an automatically deduplicated count of unique ads. One campaign can contain several affected resources, and a shared asset can have several associations. The agency should explain the count in terms of reported items and use the actual hierarchy to determine operational impact rather than multiply or merge consequences without evidence.
The collector orders findings by severity and then location. Blocking items appear before restrictions, helping the operator inspect the most consequential states first. That ordering is not a commercial-loss calculation. A blocked item in a retired paused campaign may be less urgent than a limited item in an important planned launch. The agency still needs current management and business context before assigning priority or telling a client which issue matters most.
Policy coverage does not automatically include every Merchant Center product condition, website implementation defect or external verification workflow. Those require their relevant sources. A product failing to show can involve feed eligibility, inventory or campaign inclusion rather than an ad policy decision. Choose the appropriate tool for the question. The policy collector is useful precisely when its scope is understood, not when it is advertised as a universal explanation for every absence of traffic.
Preserve unread surfaces and bounded output
The collector uses settled results so one failed surface does not erase successful evidence from the others. It records which surfaces could not be read. The command prints that warning before the result and explains that anything there is not counted. An agency should preserve this boundary in its client summary. Nothing found on the readable surfaces is different from a complete account-wide clean result, and the latter should not be claimed when part of the evidence is unavailable.
A permission problem, unsupported resource or provider failure can produce an unread surface. The failed surface does not become a zero count. Investigate or retry the relevant portion rather than launching unrelated calls to make the report appear complete. Successful findings remain useful, but their coverage needs to be retained. This gives the agency a concrete answer and a concrete missing-evidence task instead of either a blank report or false certainty.
The deterministic Slack message names at most ten findings and counts the remainder. Ten visible rows therefore do not imply ten total items. Read the stated total and overflow before telling the client the scale of the issue. If a deeper inventory is needed, use the appropriate fuller workflow or ask the assistant to focus on a specified campaign or resource. The short command message is an orientation, not an exhaustive remediation document for every item.
The collector retains policy topics, while the current compact command renderer shows resource, effect, context and review state rather than printing every topic. Do not claim that the brief command text alone contains the complete policy explanation. A specific diagnosis should obtain or inspect the relevant topic detail through an available read or Google's policy details. This distinction prevents the agency from mistaking a concise surface summary for all the evidence necessary to choose a correction.
Reconcile policy findings with the audit
The audit's disapproved-ad check covers enabled ads in enabled campaigns and ad groups. It groups the affected counts by ad group and campaign. This is narrower than the policy collector's non-removed ad coverage and different from its combined resource list. Two totals can therefore differ without either calculation being wrong. Establish the population before interpreting the discrepancy or claiming that the app missed some disapprovals.
The audit finding does not offer a universal automatic correction. It directs the owner to review the policy issue or replace the ad. That is appropriate because different violations can concern text, assets, destinations or account requirements. The agency should not advertise a one-click fix for every disapproval merely because other audit settings have dedicated actions. A visible issue and an implemented automatic remedy are separate capabilities.
A clean active-ad audit result also does not prove there are no paused disapproved ads waiting for a future launch. Conversely, a policy finding on a paused resource does not establish current active spend loss. Use the report that matches the question. The agency disapproval-audit guide discusses the setting-check workflow, while this question guide focuses on recorded reasons, triage and ownership of the actual correction.
Keep time boundaries visible. An audit snapshot, a current policy read and an old email may have been collected at different times. A status can change during review, and another operator can edit the resource. Compare like-for-like evidence before calling a discrepancy a defect. The agency can explain that the earlier snapshot showed one state and the later read another without pretending the two observations describe a single unchanged condition.
Investigate the actual policy topic
The topic identifies the reported requirement to investigate. It is more useful than a speculative list of every advertising policy, but it is not always a complete account-specific root-cause explanation by itself. Read the affected creative or destination alongside the topic. The agency should say which decision Google recorded, then establish the applicable evidence and next action. This separates confirmed provider facts from the team's explanation of how to correct the content.
A broad topic can apply to several resources, but similar labels do not prove a shared cause. Two ads may have different destinations, assets or regional requirements. Group related work only after confirming the actual relationship. The agency can save time by correcting a genuinely shared issue, while avoiding a bulk change that alters unaffected creative. A shared policy name is a starting clue, not authority to replace every ad under a client account.
Distinguish a content requirement from a technical destination issue or a certification condition. The responsible owner and evidence differ. Copywriters can revise actual claims, developers can fix destination behaviour, and the client may need to supply business verification. The assistant should identify that handoff clearly. It should not imply that a clever rewrite resolves every policy decision or invent an external approval that the account has not obtained.
Use official policy material for the relevant requirement. A remembered general rule can be stale or incomplete, especially for restricted offers and market-specific conditions. Research the exact policy when the investigation needs it, and link the source near the claim. Keep source-derived explanation concise and make the proposed account action specific. The client should receive a reasoned next step rather than a copied policy catalogue that obscures the actual affected resource.
Assign destination work to the right owner
A destination issue requires examination of the actual page and its behaviour, not just the visible domain in the ad. A page can redirect, fail under particular access conditions or contain content relevant to the reported decision. Assign the website work to the owner who can inspect and change it. The agency should not treat an RSA rewrite as a universal destination repair, especially when the campaign still points to the same affected page.
Check the supplied final URL and intended landing page. A typo or wrong destination can be a concrete account correction; a site implementation issue can require work outside Google Ads. Keep those scopes separate. A bare domain can be normalised for supported ad creation, but adding HTTPS text does not by itself prove the destination works or meets policy requirements. The agency landing-page guide also distinguishes configured URLs from broader destination behaviour.
When a developer reports a repair, collect the relevant evidence before asking for another review. The agency should know what changed and which affected ads still use that destination. Do not submit a new unrelated URL merely to make a visible field look different. The correction needs to match the reported problem and intended offer. If the destination cannot be repaired, a different compliant page is a business decision requiring the client's actual approval and supplied content.
Keep launch communication specific. A repaired page is one fact, an updated ad is another, and a later provider policy result is another. The agency should not announce that campaigns are restored merely because the website owner says the page is reachable. Inspect the relevant resource state and parent management conditions. This gives the client a useful sequence of completed and pending tasks rather than a misleading single claim that the entire incident is fixed.
Review creative and associated assets
A text-related finding should be examined against the actual complete creative, not a remembered headline from an earlier campaign. The ad may have several headlines, descriptions, display paths and associated assets. Identify the affected content and proposed correction. The assistant can help rewrite truthful copy, but a suggestion is not evidence that Google will approve it. Keep creative reasoning separate from the provider's policy decision and later review result.
An asset finding may concern a logo, image, video or other creative association. Replacing RSA text would not automatically remove that asset or resolve its finding. The agency needs the actual resource and association to determine the valid operation. A generic API field is not enough to promise that every asset can be replaced in every campaign family identically. Resolve current support through the capability framework and explain any concrete limitation before preparing an edit.
Shared content deserves careful scope. One asset can be used in several places, and an account-level association can differ from a campaign association. A requested removal or replacement should identify the affected relationship and preserve unrelated intended uses. Do not treat a recognisable name as proof of a single resource. Parent context and current association evidence help the agency avoid fixing one incident by accidentally removing useful creative elsewhere.
Ordinary creative requests should stay conversational. If the client asks for five headline ideas, the assistant can use the known offer without triggering Keyword Planner or other research by default. A live rewrite requires the complete intended creative and a prepared operation. That distinction makes the discussion faster and more useful while preserving approval for actual changes. The agency can collaborate on ideas before deciding which supported account action, if any, should follow.
Check account-level restrictions
The policy collector includes account state because an account-level restriction can dominate the serving consequence. Suspended, closed or cancelled states are not repaired merely by changing an individual headline. The agency should identify the highest relevant restriction before promising that an ad correction will restore traffic. An ad can have a usable content state while its account remains unable to serve, so one layer should not erase the other in the explanation.
The account reader exposes the returned state rather than a complete account-specific enforcement dossier. Do not invent the exact reason for suspension from a status alone. Obtain the relevant provider notice or support context where needed. The client may need to supply verification or business information outside the app's edit workflow. A useful agency response states the observed account condition and assigns the next evidence task instead of fabricating a convenient cause.
Keep account actions distinct from creative operations. Preparing a supported ad replacement is not an appeal of an account restriction. Recreating content in another structure is not automatically an appropriate response. The agency should follow the relevant provider route and client's actual business requirements. This protects the incident response from becoming a series of unrelated edits that cannot address the restriction and make later review more difficult to understand.
When the account condition changes, reread the relevant state and then assess the remaining resource findings. A restored account may still contain disapproved ads; corrected ads may still sit under paused parents. The final client update should identify which layer was resolved and which remains pending. This prevents an overly broad success claim and gives the account team a concrete checklist of current conditions rather than a stale summary from the first incident read.
Prioritise by the actual campaign consequence
Severity ordering is useful, but agency priority also depends on the client's plan. A blocked creative in an old paused campaign may be less urgent than a limitation affecting an imminent launch. Identify active or planned use, relevant destinations and other available creative. Do not equate the number of policy findings with the amount of lost revenue. The report supplies resource states; commercial impact needs its own scoped evidence and business interpretation.
A campaign can have several ads, so one disapproval may not explain a complete traffic stop. Establish which resources are otherwise eligible and intended to serve. Conversely, a single affected shared destination can matter across several campaigns. The agency should investigate the actual relationships rather than multiply a finding count by a generic loss estimate. A concrete priority statement can explain the affected launch or structure without inventing a monetary consequence.
If the client asks for performance impact, select the relevant period and commercial measure. Primary conversion value, purchase-only value and lead counts have different meanings. The absence of recent conversions alone does not establish a policy cause. Compare the affected resource context with dates and other changes, preserving uncertainty where the evidence does not establish attribution. A policy fact can be certain while its share of an observed business decline still needs investigation.
Assign a next action and owner for each priority item. The agency may own copy, the client may own claims or verification, and a developer may own the destination. Avoid leaving all findings in one undifferentiated queue. Related tasks can be grouped where they share a confirmed cause, but their resource and completion states should remain traceable. This makes the incident manageable without pretending that one bulk action can resolve every resource type.
Follow an illustrative agency incident
In an invented example, Tessa Vale at Maple Media supports Alder Workshop Services. The names and events are illustrative, not customer results. The client says that a launch has stopped because all ads are disapproved. Tessa runs the policy command in the connected channel. The result includes a limited asset, a disapproved RSA and an unread keyword surface. She keeps the unread boundary and does not repeat the client's claim as a complete account-wide finding.
The current ad evidence identifies the RSA in the Workshop Visits group. Its parent campaign is paused while the team prepares launch materials. The destination topic leads the developer to inspect the actual page, while the limited asset is assigned to the creative owner for a separate review. Tessa explains that these are distinct conditions. Fixing one ad is not the same as enabling the campaign, resolving the asset limitation or completing the unavailable keyword read.
After the destination owner supplies the corrected page, the agency prepares complete revised RSA content. The assistant can help with truthful wording from the known offer context without calling research tools unnecessarily. Tessa requests the supported replacement, and its confirmation includes the full creative, final URL, path and pin consequences. The authorised owner confirms. The resulting configuration is verified, while the provider's later policy review remains a separate pending fact.
Tessa checks the policy state again at the appropriate follow-up and reviews launch management separately. The client receives a concise update identifying the corrected content, current policy outcome and any parent still paused. The keyword surface is not called clean until it is actually read. The example demonstrates evidence, ownership and per-effect completion, rather than a broad claim that a single creative change fixed every condition initially described as disapproval.
Choose a supported correction
The proposed action should address the recorded issue on the actual resource. It might be a supported content replacement, a destination update, an asset operation or a task in Google's own interface. Do not select a familiar edit merely because it is available. The agency should explain how the intended effect relates to the policy evidence and what it cannot establish. A correct setting mutation is useful only when it is the right intervention for the incident.
Discover support through the shared capability catalogue. It describes operations, field behaviour and dependencies; it does not guarantee that every provider setting is available for every resource or campaign family. Use local metadata to identify the valid shape, then obtain the live target evidence needed for the request. This avoids both one-off tools tied to a single incident phrase and unsupported claims that the assistant can repair every disapproval automatically.
A creative correction can be prepared without claiming compliance certification. The agency should verify the supplied content against the applicable requirement and client's actual offer. The app can validate a request and read back its configuration, while Google still decides policy eligibility. Preserve that boundary in the proposal. A confirmation should not promise that the ad will pass review merely because the text meets length limits or the final URL is syntactically acceptable.
Where the appropriate action is outside current app support, make the handoff concrete. Identify the resource, issue, owner and provider route needed. Do not apply a partial unrelated edit and then imply the whole request succeeded. The agency can still use the assistant for explanation and preparation. A clear boundary is preferable to hidden routing into another product surface or a vague message that leaves the client unaware of the actual work remaining.
Review full RSA replacement effects
The current dedicated existing-RSA replacement supplies the full desired headlines, descriptions and final URL. It is not an isolated patch to one phrase unless the complete intended creative is prepared accordingly. The agency should review all supplied content and preserve what it wants retained. A conversational suggestion about one headline should not silently discard other useful assets. The proposed operation needs enough detail for the authorised owner to recognise the complete resulting ad.
Omitted display paths are cleared in this replacement flow, and headlines and descriptions are unpinned. Those effects matter when the agency has a deliberate brand or compliance structure. Include them in the review rather than hiding them behind a general replace text label. The status is retained, so a paused ad remains paused and an enabled ad retains that management state. Policy review is a separate process and does not become an automatic status change.
The supplied final URL should be the intended landing page, not an invented destination selected solely to avoid a policy label. A bare domain can be normalised where supported, but the enterprise's actual page purpose still matters. If the agency wants a different destination, confirm it with the content owner. The replacement can establish configured URL and creative fields; it does not independently prove that every redirect, page requirement or regional eligibility condition is satisfied.
Use the actual compatible ad target and parents. An RSA operation should not be proposed against a different ad family merely because its content resembles a search ad. Current capability and state checks determine the valid path. The agency approval-workflow guide provides related context for making the prepared effects clear and keeping the person's confirmation as the boundary before live mutation.
Keep replacement creation and enabling distinct
Creating a new ad is different from replacing an existing one. The current dedicated standard Search RSA creation starts paused. It requires the compatible existing group, complete desired content and destination. A paused creation is a useful preparation state, but it does not automatically enable the ad or parent. The agency should show those additional effects separately if the client requests them, rather than announce a live replacement merely because new content was uploaded.
The old disapproved ad can remain in the account unless an explicit supported operation changes it. Creating another RSA does not itself remove the old finding. The agency should decide how to manage the original resource and describe the intended scope. A new asset identity also does not transfer historical metrics from the old item. Keep the performance history and configuration result separate so later analysis does not treat the new ad as the same unchanged resource.
Dependencies need the correct order. A new ad requires an existing compatible group, and a new group requires its appropriate campaign. The local dependency framework can plan the sequence without unnecessary provider reads for stable schema facts. Live existence, compatibility and authorisation still need focused evidence. Do not assume that a successful creative generation step supplies every prerequisite for uploading, enabling and serving the result in the client's account.
If the requested chain cannot be fully supported, explain the limitation before executing a subset. A client asking to create and launch expects the necessary effects to be accounted for. The agency should not receive a final message listing only creation while silently omitting enablement. One confirmation can cover a supported prepared sequence, with each action clearly separated. Oversized requests should be reduced explicitly rather than losing operations inside a wall of text.
Use Google's review and appeal routes appropriately
Google distinguishes correcting content from disputing a decision or asking for review after changes. The agency should choose the route that matches the actual evidence. An appeal is not a generic substitute for inspecting the topic, and rewriting compliant content is not automatically necessary when the team believes the classification is wrong. Record the reason and affected resources. The provider's interface and policy requirements determine the appropriate submission and follow-up path.
The current dedicated creative edit flow is not a universal appeal engine. Do not advertise that confirming an RSA replacement submits every possible policy appeal or resolves all certification requirements. A provider API method existing elsewhere does not prove a production app route implements it for the affected resource. The agency can prepare evidence and use Google's relevant review process where needed, while supported configuration changes remain clearly described as their own operations.
Google's current guidance includes appeal limits and warns against repeated duplicate submissions. It also states that direct appeals for decisions older than six months are unavailable from 21 July 2026, with support as the route for those cases. Check the current official page when applying that requirement to an incident. The agency should not repeatedly resubmit an unchanged request merely because the first outcome was slow or disappointing.
Keep the appeal result distinct from configuration verification. A content field can be correctly changed while the policy outcome is still pending, limited or unsuccessful. The client update should identify the actual current state and next owner task. If the provider reports a partially successful review, preserve that scope rather than call every resource approved. A useful agency incident record separates submission, current review status and confirmed policy outcome for the affected items.
Prepare a useful handover
A handover should include the readable account, resource, parents, recorded topic and observed state. It should say what the recipient needs to inspect or change and why. Avoid a bare screenshot or a generic instruction to fix policies. The developer, content owner or client contact needs enough context to work on the correct item. Preserve the actual evidence boundary, including unread surfaces and the date of the observation where it affects interpretation.
Keep sensitive operational details out of ordinary client-facing URLs and messages. The recipient can locate the item through readable context and the appropriate authenticated surface. Internal emails and provider IDs are not a substitute for a usable description. An agency can maintain precise execution identity behind the scenes without publishing it in every handover. When a fuller report is needed, its access and content should match the authorised client's scope.
State completion criteria for each task. A developer may confirm a destination repair, a copywriter may deliver revised wording, and the operator may confirm that the ad configuration matches it. Google may then return a later policy state. These are separate milestones. The handover should not collapse them into one unchecked fixed label. Clear criteria help the agency report progress without prematurely telling the client that all serving conditions have been restored.
Record concurrent changes where they affect follow-up. A campaign pause, URL revision or measurement change can complicate interpretation of later traffic. The agency change-history guide describes investigation of account changes without treating a bounded sample as complete causal proof. The incident record should connect the verified correction to the next check while preserving the limits of what the available history and performance evidence establish.
Investigate in the connected Slack conversation
The deterministic starting command is /ppctor policy. It acknowledges the request and posts its deferred result because several provider reads do not reliably fit Slack's initial response window. The agency should expect a receipt and then the findings, rather than treat the acknowledgement as the completed investigation. The current command's concise list gives orientation, while a specific question needs the relevant resource and policy detail to support a diagnosis.
A natural conversation can ask about the selected campaign or follow up on a known finding. The assistant should retain the account, resource and business context when clear. It can explain the returned state, help organise owner tasks and brainstorm truthful creative from supplied information. Current policy claims still need actual evidence, and live changes still need preparation. Conversation should remain flexible without making every message trigger a fresh broad account read.
Requested tables or charts should use the relevant returned data and compatible measures. A count of policy items is not automatically a conversion or revenue series. If the client wants performance context, select that separate report with dates and definitions. Normal metrics should not exceed two decimals. Native chart limits and readable date labels apply where a chart is actually requested; the assistant should not produce unrelated visuals merely to make a policy reply look more substantial.
Normal conversational replies place the user mention before the final feedback section, which remains last. Execution progress is a distinct visible state without a mention. Keep the language concise and polite, and show actual steps rather than internal tool arguments. The agency needs to know whether it is receiving evidence, reviewing a proposal or waiting for a live change. Clear presentation is part of reliable execution because it reduces duplicate clicks and mistaken assumptions about completion.
Use shared capabilities and focused reads
The reporting and edit frameworks should describe available fields, resource semantics and dependencies through a local catalogue. The assistant can choose an appropriate read or operation from that catalogue instead of a dedicated patch for one disapproval question. Stable schema discovery does not need another provider request. Current target evidence does. This distinction supports agency scale by reducing unnecessary calls while retaining the checks that make account-specific conclusions and mutations reliable.
Reuse established context and returned data when the follow-up concerns the same scope. A discussion of one known RSA should not reread every campaign merely to recover its name. A requested chart can reuse appropriate returned data rather than fetch the same series again. Conversely, a live mutation cannot rely entirely on an old snapshot if relevant state may have changed. Focused reads give the agency a responsive workflow without confusing efficient reuse with skipped authorisation or target checks.
Use exact conditions and logical operations when prioritising evidence. Above differs from at least, below differs from at most, and both conditions differs from either. The grouping also matters: an ad finding, group count and campaign total are different records. Preserve those semantics across outputs. A request for active campaigns with disapproved ads should not silently become all non-removed policy items or a count that includes unrelated asset and account findings.
Before execution, resolve the actual target, valid field or action, dependencies and relevant current state. Do not infer support from a display label alone. An unsupported operation should be explained before any partial mutation. The agency can still receive useful preparation, but the live plan must match the requested end state. This shared logic is more durable than an incident-specific instruction that happens to work for one RSA while failing for another asset family.
Confirm every effect before execution
The proposal should show the exact readable target and desired result. An RSA needs its ad context, group and campaign; an asset operation needs its actual relevant association. Multiple effects should appear as clear steps, with each operation on its own row or section. A client should not have to interpret JSON-like text to know which content is replaced, which URL is set or which resource becomes enabled.
Use one confirmation for a supported prepared sequence, keeping every effect visible. If the request exceeds the supported safety boundary, ask for a smaller request rather than silently dropping later steps. Creation, replacement, parent status and other operations have distinct consequences. The person approving the plan should be able to see the whole intended change. A convenient partial proposal is not a faithful implementation of a larger request merely because its own mutation succeeds.
The notice is concise: “No changes have been made yet. This proposal expires in 15 minutes.” Confirm and Execute begins the live operation. After the click, visibly acknowledge change in progress and prevent repeated submission of the same proposal while pending. The agency should not have to inspect a dull message to discover whether the button registered. Clear progress separates approval from final execution and helps avoid accidental duplicate requests.
Ownership, expiry and relevant state checks remain behind the concise review. If another operator changed the target materially, report the conflict and prepare an appropriate fresh plan rather than applying a stale assumption. The approval covers the described effects, not later automatic optimisation or unrelated repairs. Scheduled Rules require their own explicit configuration. A one-time policy correction should not become hidden authority for ongoing creative or campaign changes.
Verify the edit and check policy separately
Validation checks the prepared request before mutation; verification checks relevant evidence afterwards. Neither is the same as Google's policy approval. A valid request does not prove it was executed, and a successful creative readback does not prove the new content passed review. Keep these outcomes distinct. The agency can report a verified configuration change confidently while stating that the provider's current policy result remains a separate fact to inspect.
A prominent Executed and Verified result should list confirmed effects using readable names and correct parent context. It should not contain undefined parents or asset IDs in ordinary output. The status establishes what the account now contains, not guaranteed traffic or improved business performance. Parent management, budget and policy eligibility can still affect serving. A clear success message should remain specific about its verified accomplishment rather than claim every condition of the campaign is resolved.
If different steps have different outcomes, report each accurately. An ambiguous mutation response should be reconciled against current state before a retry, because blind replay can duplicate a creation or alter content twice. A verified first step and an unconfirmed second step do not justify one blanket success statement. The user needs to understand what is established and what requires review before asking for another live change.
At the follow-up, inspect the relevant policy state and intended parent status. Preserve any still-limited or unread resource and the actual scope of a successful review. Configuration history and new resource identity should remain distinct from prior performance. The agency should close the incident only against its concrete completion criteria, rather than stop at an accepted API request or a hopeful expectation that the provider will eventually approve the content.
Maintain an agency response routine
Give each incident an owner, current evidence, intended correction and next check. This makes a handover usable across strategists, copywriters and developers without relying on memory of a Slack thread. Preserve the client account boundary and actual resource hierarchy. A routine should support thoughtful investigation, not force every policy label through the same automatic rewrite. The agency's process is strongest when the intervention matches the recorded issue and the client's real offer.
Review repeated incidents for a confirmed shared cause. A recurring destination fault can justify a site-level investigation, while similar creative findings can justify clearer authoring guidance. Do not infer a common cause merely because several items share a broad topic label. Use actual associations and evidence. Improvements to process can reduce repetition without promising that an agency checklist prevents every future provider decision or replaces Google's current policy requirements.
Monitoring and scheduled automation are separate workflows. The agency alerts guide explains monitoring context, but a single conversational edit does not authorise recurring creative changes. Any automation needs its own supported configuration and intended response. The incident result should say what changed now and who will inspect the next state, rather than imply that the app will continuously fix all future disapprovals without further review.
A useful agency answer connects the recorded policy decision, actual affected resource, complete coverage boundary and accountable next action. It separates creative ideas, supported mutation, provider review and commercial consequence. ppctor supplies accessible evidence and approval-based operations through shared frameworks; the agency supplies client context and responsible evaluation. That combination produces a response the client can understand and the team can verify, without turning missing traffic or a brief policy count into an invented diagnosis.