What permissions does ppctor need? Review each connection before using it

Review the Google grant and Slack installation separately

ppctor requests Google identity, Ads, Merchant Center and read-only Analytics scopes at sign-in. Slack installation separately requests bot scopes for messages, destinations, identity checks and supported files. These authorize the connection; a supported conversational Ads edit still requires its own confirmation, and configured Rules have their own action setup.

A permission review should name both the provider and the feature. Reading Analytics revenue, posting an audit to Slack and pausing a campaign use different parts of the setup. One broad phrase such as “account access” obscures the differences that matter to the owner.

The current Google Ads authorization is broader than read-only. Ordinary audits and account questions can still perform reads without editing anything. That is an operation boundary rather than a narrower OAuth grant.

Slack installation does not itself connect every channel to a Google Ads account. The owner selects the appropriate account context and destination. A workspace app can have valid permissions while a particular channel still needs its account connection before the requested data tool is available.

Use the current consent and installation screens together with the scope lists below. Confirm the identity, workspace and account you intend to use. A successful authorization is useful only when the chosen context and output audience match the intended business workflow.

The Google sign-in request contains six exact scopes

The current sign-in flow requests the following scope identifiers. Identity and service permissions are shown separately because they serve different purposes. A scope identifier is precise; the description explains how the current product uses it.

Scope	Purpose in the current connection
openid	Establish the Google sign-in identity.
email	Identify the signed-in account's email.
profile	Read basic profile information for the signed-in user.
https://www.googleapis.com/auth/adwords	Access supported Google Ads data and authorized operations.
https://www.googleapis.com/auth/content	Access connected Merchant data for current read and analysis features.
https://www.googleapis.com/auth/analytics.readonly	Read supported linked Analytics information and aggregate reports.

Google's scope reference describes the service permissions. The Ads scope includes management capability; the Shopping scope also has a broad label. The Analytics scope is explicitly read-only. These different descriptions should not be flattened into a single claim that all connected services are read-only.

The requested list is not necessarily the same as the granted list for an individual sign-in. A user can decline relevant optional access. The app records granted Merchant and Analytics state so the corresponding feature can distinguish unavailable authorization from a legitimate empty result.

Google sign-in is also separate from selecting a provider account inside the app. The account selection identifies which reachable business account a workflow uses. It does not rewrite the scope list or imply that the consent was technically limited to one Slack channel.

Keep the exact scopes in an internal review reference when required. The reviewer can then check the consent screen against the feature purpose without relying on an abbreviated description such as “connect Google.”

An email identity scope is different from access to a Gmail inbox

The identity scopes let the app establish who signed in and show relevant profile information. They do not request the contents of the user's Gmail inbox. The current scope list contains no Gmail message-reading permission.

The app reads the signed-in user's name, email and profile image reference as part of the connection. This supports session identity and account relationships. It does not mean the app received the Google password or can read every service attached to the same identity.

Authentication happens with Google. The application receives the authorization response and obtains the credentials needed for authorized calls. You should not send a password, session cookie or OAuth token to the assistant in a conversational message.

A user identity can own several provider relationships. Knowing the email is not enough to establish access to a particular Ads account or Analytics property. The provider relationship and app selection remain separate checks.

The identity information is stored with the relevant session and user records. A record's retention depends on its purpose; the basic session lifetime is not a blanket expiry for every saved connection or user-created record.

For a client-facing handover, use the business account name and responsible role where sufficient. Reproducing the signing-in person's email in an ordinary report usually adds no value. Exact identity checks can happen within the application without exposing private identifiers in the output.

The Ads scope authorizes access; the operation determines what happens

Google's Ads OAuth overview explains using authorization for account access without handling the user's login information. Provider account access remains relevant alongside the scope and the application's API configuration.

ppctor uses Ads reads for account questions, performance, policy and audits. A request to compare cost, list current conversion actions or inspect campaign settings does not authorize an edit. The assistant should answer the requested question using supported evidence.

The same broader grant supports implemented authorized Ads operations. A supported conversational request prepares an exact proposal and requires confirmation. The proposed action is not already executed because the user can see an approval message.

Configured scheduled Rules are another explicit workflow. Their saved condition and action define the intended automation. An owner reviewing access should check those enabled configurations instead of assuming all activity is governed by a fresh Slack button every time.

The broad scope does not imply every possible provider setting is exposed by every tool. Individual operations have valid targets, prerequisites and supported contexts. A target that can be read may still be ineligible for a particular write.

Use accurate language in an organizational review. You can describe an audit session as read-only work. You cannot describe the current Ads OAuth grant as a dedicated read-only scope. The permission and operation controls need to be evaluated together.

The Merchant permission label is broader than current tool behavior

The Merchant connection uses the content scope. The current sign-in requests it so product status, feed-health and supported Shopping Analysis features can read relevant data without a separate authorization step for each question.

The current Merchant tools read and report products, issues and supported analysis results. They do not rewrite the client's product feed. A broad provider permission label should not be misrepresented as evidence that the current app performs Merchant mutations.

The selected Merchant relationship matters. An accessible Merchant account is not automatically the account intended for a particular Ads campaign. Establish the linked catalogue before interpreting a product status or benchmark result.

Declined scope, missing relationship and no matching report data are different states. A useful response identifies which applies. It should not ask the user to broaden a product filter when the actual problem is that the service access was not granted.

Product inclusion in an Ads listing group is a different operation from editing the Merchant product. It changes campaign selection under the Ads workflow. It does not approve the item or repair a feed issue, even if both features concern the same catalogue product.

For a permissions handover, record the Merchant purpose and selected relationship. That lets a reviewer understand why the scope is requested, what the current tools do and which further prerequisites a Shopping report needs.

Analytics access is read-only and depends on the linked property

The Analytics scope permits supported reads. The app uses linked property information and aggregated metrics for reports, monitoring and MER-related analysis. It does not use that read-only authorization to change the property's event configuration.

A property must be the one intended for the account question. Linking the wrong property can produce a technically valid but misleading comparison. Confirm the business context and property relationship before interpreting revenue or event totals.

Named-event comparisons need the corresponding event selected. The assistant can inspect relevant event names and suggest a plausible mapping, but a site-specific lead event must be confirmed when needed. A broad scope does not define the business meaning of that event.

A request to show two metrics in one chart affects presentation. It does not change the Analytics property or configure a new event. Retain the requested metrics, dates and populations so the visual represents the same read.

If Analytics access was declined or no property is linked, explain the prerequisite politely. Missing access is not zero revenue or zero sessions. The feature should not silently substitute an unrelated property to produce an answer.

Disconnecting the property in the app removes that relationship and pauses relevant dependent monitoring or scheduled outputs. It is distinct from revoking the shared Google authorization and from deleting retained observations.

The Slack installation requests fourteen bot scopes

The current Slack installation requests the bot scopes below. It does not request a user-scope token to act as the installing person. Slack's OAuth installation guide distinguishes bot scopes from user scopes and describes the grant process.

Bot scope	Current feature purpose
app_mentions:read	Receive messages mentioning the app.
chat:write	Post bot replies and supported output.
channels:read	Discover public-channel destination information.
groups:read	Discover accessible private-channel destination information.
channels:join	Join a selected public channel where supported.
channels:history	Support relevant public-channel message and thread handling.
groups:history	Support relevant accessible private-channel message and thread handling.
commands	Make the slash-command workflow available.
im:write	Open supported direct-message destinations.
users:read	Resolve user information for supported selection and identity checks.
users:read.email	Resolve the relevant user's email for connection identity checks.
files:write	Upload supported report files.
files:read	Read supported deliberately selected Slack files.
reactions:write	Add supported progress reactions; optional for a valid installation.

These are requested capabilities, not a statement that every feature exercises every scope on every request. The account question, destination and selected output determine which parts of the connection are used.

The current exchange checks the required granted bot scopes. Reactions are requested but treated as optional, so missing reaction permission does not alone invalidate an otherwise complete installation. Required missing scopes need the proper installation flow rather than an invented data result.

Review the workspace you are authorizing before completing installation. Installing into the wrong workspace is a context mistake that permission text cannot repair. The correct app grant and the correct destination relationship are both necessary for the intended workflow.

Message permissions support mentions and relevant thread follow-ups

Mention delivery and ordinary thread-message handling are different parts of Slack interaction. The app needs to receive the initial mention and relevant follow-ups that may not repeat the mention. Otherwise a natural conversation can appear to stop after the first answer.

The current installation requests public and private channel history-related scopes for that supported handling. Slack's channels history scope reference describes the corresponding capability. Actual channel access and the app's conversation rules remain relevant.

The requested capability should not be described as a guarantee that every workspace message is part of every model prompt. The assistant uses relevant thread context for the question. The application's scope and its chosen conversation behavior are separate layers.

Stored thread context helps reduce repeated provider history reads and supports follow-ups. It has a seven-day lifecycle for conversational continuity. That is different from the normally ninety-day diagnostic conversation records described by the current policy.

A phrase such as “show the same data as a chart” should retain the resolved metric and period. Context supports that interpretation. It does not make the phrase permission for a live campaign change.

Review the output audience along with input context. A concise answer can still contain sensitive business amounts. The channel's members can see the delivered response, even when the request and provider operation are entirely read-only.

Destination discovery and channel membership are different

The channel-read scopes support destination selection. Public and accessible private channels differ in how the bot can join. The current public-channel join capability does not let the app automatically join a private channel without the relevant invitation.

If a private channel is intended, ensure the app has been invited and the connection points to that actual destination. An unavailable private destination should be handled as an access or membership issue, not as proof that the account has no data.

A selected channel is tied to the relevant account workflow. The owner should review the mapping when moving between clients or workspaces. A valid Slack token alone does not identify which Google Ads account belongs to every channel.

Direct-message destination support is another capability. It does not imply the app requests every possible direct-message history scope or acts as the person being messaged. The bot identity posts the supported output.

Workspace administrators may have their own app-approval process. Use the actual requested scopes and current feature purposes to support that review. Do not assume a completed Google authorization overrides the workspace's installation requirements.

For a practical test, verify the intended destination with a read-only account question or supported report. That tests the account mapping and delivery context without requiring a live Ads mutation merely to prove the installation works.

User lookup supports identity checks rather than public email output

The user-read scopes let the app resolve supported user information. The email-specific scope supports matching the relevant Slack identity to the connected owner in appropriate approval workflows. An internal identity check is different from printing someone's email in a report.

Slack's email scope reference describes that access. The ordinary user-read permission alone should not be assumed to supply every email field needed for an identity-dependent feature.

A button interaction identifies the Slack actor, but authorization still needs the relevant app-side checks. A visible confirmation button is not evidence that every person in the channel can execute the proposal. The operation flow checks the authorized context separately.

User identity should remain distinct from account selection. A person can belong to the workspace without owning the connected Google authorization. A channel audience and an approving identity can therefore differ.

Normal output can use a user mention where appropriate. It should not append private email addresses or internal user IDs merely because the application can read them. The report should make the business finding and requested action clear.

If identity cannot be confidently verified for an operation, do not bypass the check to make a button work. Establish the correct connection or installation state. A clear refusal or required reconnection is preferable to treating a mismatched identity as authorized.

File access and reactions support specific presentation workflows

The file-write scope allows supported reports to be delivered as files. A fuller output can be useful when data would overwhelm a Slack reply. File creation is presentation and app storage work; it does not mean the provider account was edited.

The file-read scope supports deliberately selected Slack files in the relevant asset workflow. Slack's file-read scope reference describes the capability. The current feature purpose should not be expanded into a claim that every workspace file is imported.

Before selecting a file, confirm that it is appropriate for the connected business and intended audience. Uploaded creative can have its own licensing, privacy and business context. The scope authorizes access; it does not establish those facts about the selected material.

Reaction permission supports progress feedback. It is optional in the current required-scope check, so missing it should not prevent an otherwise valid installation. A reaction is a UI acknowledgment, not proof that an Ads write completed.

Operation progress and final results must remain clear even when an optional reaction is unavailable. A change-in-progress state and a verified-execution message serve different purposes from a small visual acknowledgment.

Retained files and report records have feature-specific lifecycles. A generated report or imported asset is not governed solely by the seven-day Slack thread-context window. Review the relevant policy category when deciding how long the material should remain.

Installation approval establishes the granted Slack connection

The Slack flow requests bot scopes, receives installation approval and exchanges the temporary authorization response for a bot token. The current app does not request a separate user-scope grant to act as the installer.

The saved installation includes the workspace, bot identity, installer identity, granted scopes and installation time. The bot token is stored using the application's secret-encryption control. A missing or unreadable token is not a valid working connection.

The current exchange rejects an installation missing required granted scopes and permits the optional reaction scope to be absent. That distinction avoids treating a cosmetic progress feature as a prerequisite for all account questions.

An older installation can differ from the current requested list. A reconnection may be needed to grant newly required capabilities. The presence of the app in a workspace does not prove its stored token includes every current permission.

Installation approval is not an Ads edit approval. It enables the Slack integration's capabilities. A later supported conversational write still has its own target, operation and confirmation, while configured Rules follow their own saved setup.

Verify the selected workspace and account destinations after connecting. This confirms the intended context rather than relying only on a successful OAuth return. A read-only test can then establish useful delivery behavior before the team considers live changes.

A permission grant does not replace approval for an exact edit

A normal performance question is a read request. An audit finding is a diagnosis. A creative suggestion is a draft idea. None of those alone constitutes approval to mutate the live Ads account.

A supported edit proposal identifies the actual target and action, using readable names and valid parents. Every logical step should be visibly separate. The owner can assess what will happen without decoding resource IDs or raw provider JSON.

The proposal expires in fifteen minutes and says no changes have been made yet. Confirm and Execute authorizes the prepared operation. A supported sequence can share one confirmation with each action clearly described. If the complete request cannot be prepared safely, ask for narrower proposals before writing rather than silently executing only part of it.

Execution checks current conditions and verifies the supported result. A clear progress state acknowledges the click, and the final message distinguishes a verified operation from an accepted but incompletely verified outcome.

Ambiguous verification does not justify automatically replaying a potentially completed write. Inspect the current target before deciding the next step. The presence of a valid scope does not remove the need to avoid duplicate operations.

Separately configured scheduled Rules remain important in the access review. Their deliberate configuration authorizes their specified automation. An accurate handover includes those enabled actions instead of claiming that every future account operation always requires a fresh Slack confirmation.

Know which records support the connection and requested features

The connection stores identity and credential information, account relationships, selected destinations and feature settings. These allow the service to know which account a question concerns and where its output belongs.

Current session, Google refresh and Slack token writes use application encryption for secrets. The encryption routine refuses an unencrypted secret write when its required key is missing or malformed. That specific control should not be confused with a promise that every report field uses the same routine.

Features can store results and observations for history, monitoring or reporting. A read-only provider request can therefore create an app record. “No live edit” and “no retained data” are different claims.

Relevant questions and conversation context can be sent to the configured AI provider for inference. The current Privacy Policy names processing providers and explains the categories involved. OAuth credentials are not ordinary model-input material.

Temporary response caches have bounded lifetimes, while saved reports and configurations can have longer lifecycles. Do not characterize every connected observation as a short-lived cache merely because the feature uses caching for some reads.

For an organizational review, list the record category and business purpose. This lets the team make a meaningful decision about connection data, conversation logs and user-created records instead of trying to apply one retention assumption to every feature.

The current policy gives different periods for different records

Slack thread context has a seven-day lifecycle. The sign-in session has a seven-day storage lifetime, with refresh behavior able to save an updated session. Neither timer is the same as revoking the Google authorization.

Questions, AI answers, submitted feedback, tool-run records and operational error logs are normally retained for ninety days. The current owned log sweeps use that cutoff. Longer-lived incident or delivery reconciliation can have a separate requirement.

Slack channel links parked after disconnect remain available for restoration to the same workspace for seven days. They are hidden from active delivery during that period and are eligible for removal after the restoration window.

Connections, saved audits, monitoring and reporting configuration, and other user-created records generally remain until removed, account deletion or an applicable feature-specific retention rule. Separately stored background refresh credentials do not receive the browser session's expiry.

The policy also describes the recovery period for deleted Asset Library files and expiry of raw draft instructions and retrieved page facts. Structured revisions and review records can have a different lifecycle. Review the actual feature category when those records are part of the workflow.

Use the current policy as the retention reference. Request clarification or removal for the particular records involved instead of assume logout erases them. Provider access, active app configuration and retained information need separate review.

Remove the connection at the layer you intend to change

To stop Google authorization, review ppctor under Google Account permissions and remove the grant for the correct identity. This concerns future authorized provider access after revocation takes effect.

Google's revocation guidance explains the effect on granted credentials and combined authorization. Removing the shared grant can affect more than one connected Google service. An app-level property unlink is a different operation.

Logout deletes the current session and clears its browser cookie. It does not revoke every separately stored background credential. Closing the browser also does not disable all configured scheduled work.

Slack disconnection attempts to uninstall the app from Slack, parks its account destinations, removes the local installation token and pauses relevant Slack outputs. Provider uninstall can fail independently, so the returned outcome matters. If the app remains installed in Slack, remove it there through the appropriate workspace process.

An Analytics disconnect changes the app's selected property relationship and relevant dependent work. An account-pairing removal changes an app relationship. Neither should be described as deleting the provider account or editing the property's configuration.

Retained data needs separate handling. Earlier Slack messages and saved app records do not disappear solely because a grant is revoked. Use the current privacy policy and contact process for the desired data request, naming the relevant record category.

Review three fictional setups before connecting

Imagine invented agency Elm North evaluating an account-audit workflow. Its reviewer records the six Google scopes and the broader Ads authorization, then chooses the intended business account. The initial audit and explanation perform reads without approving live edits.

Elm North installs the app in its internal workspace and reviews all requested bot scopes. It checks the selected channel audience and existing Rules. The handover states that the current analysis session is read-only work while the grant and configured automation have their own boundaries.

Now consider fictional retailer Lake Market. It wants Merchant health and Shopping Analysis. The owner verifies the Merchant relationship and content access instead of assuming Google sign-in alone identifies the correct catalogue. A product-status report remains a Merchant read.

Lake Market later requests a product-inclusion edit in an Ads listing tree. The team understands that this is a separate confirmed Ads operation. The edit does not rewrite the feed or guarantee Merchant approval.

Finally, invented service business Harbour Repair wants a named conversion compared with one GA4 event. The owner confirms the linked property and corresponding event. The report reads both sources and posts to the selected private channel where the bot has been invited.

Harbour Repair finishes its review by recording retention and removal choices. It knows that unlinking the property, disconnecting Slack, revoking Google access and requesting stored-record deletion address different outcomes. No fictional result or business example is presented as a real customer's evidence.

Create a permission reference for the team

Write the purpose of the connection first. An audit, a scheduled report and a configured edit Rule are different uses. The reviewer should know which features the organization intends to enable before interpreting the requested scopes.

Include the exact Google and Slack scope lists and current granted installation context. Record the selected business accounts, Analytics property and Merchant relationship where relevant. Use readable names in ordinary handovers rather than expose private identifiers.

Document destinations and audience. A channel's membership determines who sees delivered information. The app's ability to post and the team's decision to use a particular channel are separate responsibilities.

Describe the approval flow for supported edits and list enabled Rules separately. An incoming operator should understand both conversational confirmation and configured automation. Avoid a blanket statement that the app is read-only or that every permitted user can execute every visible proposal.

Include retention by category and the appropriate revocation or disconnection route. Session expiry, thread expiry and saved record removal do not describe the same lifecycle. Link the current privacy policy so the reference stays connected to the actual disclosure.

Assign responsibility for maintaining the setup. Someone should review changed destinations, account handovers and automation that no longer fits the business. A concise current reference is more useful than an old consent screenshot with no feature context.

Use a feature-by-feature review instead of one blanket approval

For each planned feature, write the data source, destination and effect. An audit reads Ads configuration and can produce a saved report. A scheduled Merchant alert reads the selected catalogue and posts a finding. A configured Rule can perform its specified supported Ads action. These distinctions give the reviewer something concrete to approve.

Then record the connection dependencies. A Google sign-in can be valid while the intended Analytics property is unlinked. A Slack installation can be valid while the private destination lacks the bot invitation. The reference should identify which relationship is missing rather than treat every incomplete setup as a general authorization failure.

Review the output with the intended recipient in mind. A client may need a short performance explanation, while an internal operator may need the full diagnostic report. The same posting permission can serve both audiences, but the channel selection and report content remain deliberate business choices.

Make proposed expansion visible. If the team initially uses audits and later enables an edit Rule, update the reference to include that action and owner decision. The unchanged OAuth scope does not make the new workflow operationally identical to the earlier read-only session.

Choose a simple validation for each relationship. A focused account read checks the intended Ads context. A supported property report checks the selected Analytics context. A read-only reply in the destination checks useful Slack delivery. None requires an unnecessary campaign mutation merely to demonstrate that a connection exists.

For removal, define the desired endpoint before acting. If the objective is to stop one destination, disconnecting or changing that relationship is different from revoking every Google service in the shared grant. If the objective is to remove retained information, a provider revocation alone leaves that data request incomplete.

This reference should describe verified setup, not assumed future capability. Mark a selected relationship only after checking it, and keep a failed validation attached to its actual feature. The team can then repair the specific prerequisite without changing unrelated permissions or repeatedly reinstalling a connection that is already valid.

Include the date of the team's review in its private reference. That helps the next operator distinguish the setup checked at onboarding from a later workspace or account change. The review date is context for the evidence, not proof that the same relationships remain valid indefinitely.

Treat missing permission as missing access, not missing data

If a tool says access is unavailable, identify the relevant layer. Google scope, provider account reachability, selected property, Slack installation, channel membership and operation approval can fail independently. The response should name the actual missing prerequisite.

A declined Analytics scope differs from a linked property with no matching event. A missing Merchant grant differs from a country with no benchmark report. These states need different next steps, and none should be turned into a zero-value performance conclusion.

A Slack app that receives mentions but not required follow-ups can have a permission or event-delivery issue. The current required scope list and stored grant provide evidence for that review. Reinstalling should follow the diagnosed missing capability rather than become a universal first instruction.

Private-channel membership is another specific condition. The bot cannot assume that a channel exists merely because the user knows its name. Invite it through the appropriate workflow and verify the selected destination.

Do not solve a permission problem by bypassing target ownership or identity checks. Those checks determine whether the requested operation is authorized. A clear connection correction preserves the intended boundary and makes future behavior easier to verify.

After the connection issue is resolved, retry a focused read for the original account and feature. Keep the same question and period so the result actually answers the failed request. A different report can succeed while leaving the original prerequisite unresolved.

Frequently asked questions about requested permissions

Does the email scope let ppctor read my Gmail messages?

No. The current Google list includes identity email access, not a Gmail message scope. It identifies the signed-in user. The connected Ads, Merchant and Analytics scopes are separate service permissions.

Does ppctor post as the person who installed it?

The current Slack flow requests bot scopes and does not request a user-scope token. Supported replies use the app's bot identity. Installation context still identifies the workspace and installer for the relevant app relationship.

Why are channel-history permissions requested?

They support relevant message and thread follow-up handling, including replies without a repeated mention. Actual channel access and the app's conversation rules still determine the context used for a response.

Is reaction permission required for the whole installation?

No. It is requested but optional in the current granted-scope check. Missing it skips supported progress reactions while required scopes still govern the installation's other capabilities.

Does installing Slack authorize a campaign pause?

No. A supported conversational campaign edit needs its exact proposal and confirmation. Installation establishes Slack capabilities, while separately configured Rules have their own intended action setup.

Does removing a grant delete previously retained reports?

No. Revocation stops future provider access through that grant. Retained records and delivered Slack messages need their own handling. Review the current privacy policy and request the specific data action you want.