How long does ppctor keep data? A practical retention and removal guide

There is no single expiry period for every kind of data

ppctor keeps Slack conversation context for seven days and normally keeps conversation, feedback, tool-run and operational logs for ninety days. Saved connections, audits and feature settings have different lifecycles. Revoking Google access stops new authorized reads but does not delete saved results. Start with the record category and the removal outcome you want.

The current Privacy Policy is the disclosure reference for retention and data requests. This guide explains how the categories differ in practical use. A short session or context lifetime must not be treated as a blanket promise that all information disappears after the same interval.

A useful question names the information: a Slack thread, a saved audit, a report file, an OAuth credential or an uploaded asset. Those records serve different purposes and have different controls. “Delete the connection” is incomplete when the actual intention is to remove earlier delivered results.

Retention also differs from active use. A disconnected integration can stop future delivery while some historical records remain. An expired context message can be unavailable for follow-up before a scheduled cleanup physically removes its row.

Begin by deciding whether you want to stop future processing, remove an app relationship, revoke provider authorization or request deletion of retained information. Once that intention is clear, the appropriate control and evidence become easier to identify.

Review the published categories and typical periods

The policy separates short-lived context, ordinary operational records and longer-lived user-created information. These categories provide the starting point for a review, with the relevant feature's actual lifecycle used where more detail is needed.

Record category	Current typical retention
Slack conversation context	Seven days.
Sign-in session	Up to seven days per stored session, with refresh and new sign-in behavior.
Parked Slack destination links	Seven-day restoration window after disconnect.
Questions, answers, feedback, tool-run and operational logs	Normally ninety days.
Deleted Asset Library files	Thirty-day recovery period, then scheduled permanent removal.
Raw draft instructions and retrieved page facts	Ninety-day expiry for raw content.
Structured drafts, reviews and publication records	Remain until removed or account deletion, subject to relevant lifecycle rules.
Connections, saved audits and monitoring/reporting settings	Until removed, account deletion or an applicable feature-specific period.

These periods concern different records. A report configuration can remain active while completed run evidence is subject to a ninety-day sweep. A raw instruction can expire while a structured draft revision remains. Read the category rather than infer retention from the feature's broad name.

Temporary provider responses also use bounded caches. They are separate from observations deliberately stored for history or scheduled analysis. The service does not describe all saved records as a short-lived cache.

Unresolved delivery and incident reconciliation can need longer-lived state, and individual legal requirements can affect retention. The policy identifies those boundaries. A data request should therefore ask about the actual records involved rather than assume every item is governed by the same routine cleanup.

The useful outcome of a retention review is a map of records and controls. It should tell the owner what is active, what is historical, what expires routinely and what needs an explicit request.

Identity records and account relationships have their own purpose

Google sign-in provides the name, email and relevant profile information for the user identity. The app also stores connection relationships and account context so features can operate for the intended business. Identity is not itself a performance observation or a temporary chart result.

The requested Google scopes are openid, email, profile, https://www.googleapis.com/auth/adwords, https://www.googleapis.com/auth/content and https://www.googleapis.com/auth/analytics.readonly. They define the authorization request; their presence does not define one retention period.

Account links can associate Ads with Merchant or Analytics context and Slack destinations. Removing a relationship changes the app setup. It does not necessarily delete every prior report generated using that relationship.

A selected-account change is another distinct action. It changes which account the page or workflow uses, not the historical identity of every stored observation. Keeping account context allows the service to interpret results without mixing businesses.

For ordinary output, use readable business names instead of expose internal account keys. The application may need identifiers to scope records and permissions, but those keys do not need to appear in client-facing examples.

If you want an identity or account-record removal, state that explicitly in the request. “Stop sending this report” and “remove my retained account information” have different scopes. The service may need to verify the requester's identity before acting on a broader data request.

A seven-day session is different from background credentials

The current sign-in session stores the identity, access credential, optional refresh credential, expiry and relevant granted-scope state. The session record uses a seven-day storage lifetime. Active token refresh can save an updated session, and a new sign-in can create another session.

The browser cookie carries the session identifier. Logout deletes the corresponding current session and clears the cookie. That ends the current browser session; it does not revoke every separately stored provider credential.

Background features use separately stored refresh credentials without the same seven-day session expiry. This allows configured work to continue without an open browser. The shorter browser lifecycle must not be described as the lifetime of all Google access.

Current credential writes are encrypted before storage using the application's secret-encryption routine. It refuses an unencrypted new secret write if the required key is missing or malformed. That protection is separate from the retention decision.

A provider token can expire or become invalid independently of a stored record. An unusable token means fresh access is unavailable; it does not mean every saved report has been deleted. Connection state and retained information need separate interpretation.

When leaving a shared device, end the current session. When ending provider access, revoke the appropriate grant or stop the relevant configured feature. When requesting retained-data removal, name that outcome separately rather than assume logout completed it.

Slack context expires on its own seven-day lifecycle

The app stores relevant messages it receives or delivers for supported thread continuity. The current thread-history records have a seven-day expiry, and reads select only messages that have not expired. This lets the assistant interpret follow-ups without treating the store as a permanent conversation archive.

Each stored message has its own expiry. A later reply can be part of an active conversation without making every older message permanently available. The current read also has a bounded message selection, so it should not be described as unlimited recall of the entire thread.

A separate thread marker helps determine whether an ordinary follow-up belongs to a thread the bot participates in. It also uses a seven-day lifetime. That behavior prevents unrelated channel chatter from being treated as a request simply because the bot is present.

Context supports questions such as “show that as a chart” or “use the same period.” It does not grant permission for a mutation. A supported live edit still uses its own proposal and confirmation state.

Once a stored message expires, the normal context read excludes it. Physical row cleanup is handled by the scheduled expiry sweep. This distinction explains why expiry and cleanup are related but not the same instantaneous event.

The seven-day context store is separate from ordinary conversation diagnostics and from messages retained by Slack itself. Losing app context does not erase the thread from the workspace, and a ninety-day diagnostic category does not mean the assistant uses every old log as live conversation memory.

Conversation and tool logs normally use a ninety-day period

The current policy groups questions, AI answers, submitted feedback, tool-run records and operational error logs under normally ninety-day retention. These support diagnosis, feature review and operation history, with the relevant owned cleanup routines.

The current conversation sweep deletes qualifying older conversation rows, and the tool-history sweep deletes qualifying older tool-run rows. The app supplies the cutoff through its log-cleanup composition. Each module owns the cleanup for its record category.

The cutoff is guarded against deleting inside the published ordinary retention window. That is a control on routine sweeps. It does not establish that every table in the service uses the same expiry or that a broader verified deletion request is identical to routine pruning.

Operational diagnostics differ from conversational context. A later incident investigation may need a tool outcome even after the assistant's seven-day thread context has expired. The records serve different purposes and should be described separately.

A client-facing report should not expose raw diagnostic content by default. The user usually needs the finding, readable target and next step. Private identifiers or technical payload details should remain in the appropriate restricted diagnostic context where needed.

If your question concerns a specific earlier conversation or operation, name the feature and approximate time in a privacy request. Avoid sending raw credentials as proof. The request should identify the retained category and intended action without adding unnecessary sensitive material.

Saved results are different from temporary provider-response caches

A provider-response cache helps repeated reads avoid unnecessary calls. A saved audit or observation can support later review and historical features. Those are different lifecycle decisions even when both originate from the same provider response.

Reading a campaign or Merchant status can create an app result without changing the provider account. “Read-only” describes the provider operation; it does not mean the application stores no information. This matters when evaluating both permissions and retention.

Saved audits retain the findings needed for review according to their record lifecycle. Deleting an account pairing should not be assumed to remove every previous audit. The desired retained-record outcome needs its own scope.

Historical observations can support a trend that is not available from one current snapshot. Their retention should be understood as feature history, not an accidental extension of a short cache. The current policy expressly distinguishes saved observations from temporary responses.

When a chart is requested, its selected dates and metric population describe the report, not the duration of the underlying stored record. A last-seven-days graph can come from a service that retains relevant history longer than seven days.

For a retention review, list the saved feature result separately from its temporary read cache. That produces a meaningful answer to “what remains?” without inventing a single TTL for every piece of account information.

Monitoring and reporting configuration can remain after individual runs expire

A scheduled feature needs saved configuration: the account, metric, conditions, interval and destination relevant to the feature. That configuration can remain active until changed or removed. It is different from evidence about one completed run.

The current reporting-run sweep removes completed run evidence older than its ninety-day cutoff while leaving unresolved runs for recovery. The saved report configuration is not described as expiring merely because a completed run becomes old.

Alert and anomaly observations also have their owned operational histories. A user reviewing the connection should ask about both the active setting and relevant event records. Turning off one schedule does not necessarily erase every earlier observation.

Configured Rules can perform their specified supported actions. Their existence is operationally significant even when the newest conversation was read-only. A retention review should identify whether the configuration remains active, not just when old run logs are pruned.

Disconnecting a dependency can pause relevant outputs or checks. That stops the affected active workflow without proving all historical state was removed. The returned disconnection outcome should say which configuration effect actually occurred.

When a project ends, decide whether the team wants to stop delivery, delete saved configuration or request broader retained-record removal. Those are different intentions. Naming them clearly avoids leaving an active schedule behind while deleting an unrelated report file.

Edit proposals and execution evidence answer different questions

A supported conversational edit proposal has a fifteen-minute approval expiry. That deadline governs whether the pending proposal can be approved. It should not be described as proof that every record related to the proposal is physically deleted at minute fifteen.

The proposal stores the prepared target and action with account and conversation context. Current transitions distinguish pending, executing and final states. An expired proposal requires a fresh preparation instead of treating its old button as ongoing permission.

Execution evidence records the outcome of a supported live operation. A verified setting update and an uncertain result are different states. Retaining the outcome can help avoid duplicate writes or explain a later investigation.

The app's operation history is separate from Google Ads platform history. The former concerns what this app performed; the latter can include changes made elsewhere. Removing a local record does not rewrite the platform's own history.

A proposal's appearance is not proof that a mutation occurred. A confirmed execution's result should state the exact verified or accepted outcome. The record lifecycle needs to preserve that distinction rather than treat every chat message as an account change.

If a retained execution record is relevant to a data request, identify the operation and desired scope. Do not repeatedly execute the same change to investigate a record. Inspect current state and the relevant evidence instead.

Completed delivery history and unresolved work have different lifecycles

Scheduled and interactive work can produce delivery records so the service knows whether output completed. The current completed-job cleanup removes qualifying older completed history. It does not blindly delete every job merely because it was created more than ninety days ago.

Unresolved work can remain for recovery or reconciliation. This is especially important when an external outcome is ambiguous. Deleting the state prematurely could hide whether something was sent or make a duplicate attempt more likely.

The current policy allows longer retention for unresolved delivery or incident needs. That boundary should remain in a retention explanation instead of promise automatic removal for every operational record at the same cutoff.

A completed provider call and a completed Slack delivery are different outcomes. A report may be generated successfully while delivery fails. The retained state can help the application retry or reconcile the appropriate stage without rerunning unrelated work.

For a user request, explain which outcome remains unresolved and which information is being retained for that purpose. An ambiguous send should not be presented as a confirmed failure or blindly replayed solely to make the history look complete.

A specific incident review can determine the next action. It may require current-state inspection, delivery reconciliation or a record-removal decision. The relevant state should follow that evidence rather than an assumption that every unresolved record is disposable.

Deleted assets have a recovery window before permanent removal

The current Asset Library delete action records deletion and sets a purge time thirty days later. This creates the recovery window described by the policy. Ordinary deletion from the active library is therefore different from immediate permanent blob removal.

The scheduled asset purge removes qualifying expired records and processes unreferenced stored blobs. It uses bounded work and retains deletion state needed to resume interrupted cleanup. These are practical lifecycle steps rather than one instantaneous delete at the moment the user clicks.

A shared stored blob should not be removed while another retained asset record still references it. The current purge checks for references before claiming eligible blob deletion. That is another reason the file lifecycle cannot be reduced to the active row's visible state alone.

Generated report files and uploaded creative can have different uses. Ask which feature owns the material and which records reference it. A Slack-delivered copy is also separate from a file retained inside the service.

If the owner needs a particular permanent-removal outcome, state that explicitly and use the appropriate request process. Do not assume deleting a message, revoking Google access or ending a session removes every uploaded file.

Use safe descriptions in a handover: file purpose, owning feature and desired removal state. Avoid copying private customer content into another channel simply to identify it. The team can resolve the relevant record internally without expanding its audience.

Raw instructions and structured drafts are not the same retained record

The current draft-content sweep expires raw instructions and retrieved page facts after ninety days. It preserves the structured revision, review and publication records needed for the feature's history. Raw source content and derived structured records therefore have different lifecycles.

Expiring raw text does not necessarily remove every concept derived from it. A headline, campaign plan or structured field can remain in the saved draft. The policy describes structured records as remaining until removal or account deletion, subject to the relevant lifecycle.

Retrieved page facts are also distinct from the public page itself. Removing the retained facts from this service does not alter the website they came from. A request should concern the service copy when that is the intended scope.

A draft is not a live provider asset until the relevant supported publication workflow acts. Retained draft material can exist without an account mutation. Conversely, deleting a local draft does not automatically remove an already published provider resource.

For a privacy review, identify raw instructions, structured revisions and publication evidence separately. A request to remove only raw conversation text has a different result from a request to remove all retained draft records.

Keep the product context accurate. These records have a lifecycle even when they are not the routing destination for ordinary Slack conversation. The retention explanation should describe stored categories without implying the assistant sends every account question into a draft workflow.

Slack disconnection parks destination relationships for seven days

When Slack is disconnected, the app hides active account-to-channel links and records a parked time. The parked relationship is not an active delivery destination. This preserves a limited restoration opportunity without continuing output to the disconnected workspace.

Reconnecting the same workspace within seven days can restore eligible parked links. The current restoration also checks that another account has not taken the destination relationship. A saved old link is not unconditional authority to overwrite a new assignment.

After the restoration window, the scheduled parked-link sweep removes the old parked relationship. This lifecycle is separate from the normally ninety-day operational logs and from messages already posted to Slack.

The Slack token and workspace installation have their own removal path. Disconnection attempts provider uninstall, clears the app connection and pauses relevant outputs. The provider result can differ from local cleanup, so the returned status matters.

Restoring a destination is also different from automatically reactivating every paused feature. The user should review the current configured outputs and choose the intended behavior after reconnection.

If the organization wants no restoration record retained, make the desired removal scope explicit. A temporary disconnect intended for later reconnection and a broader deletion request are different intentions, even though both begin by stopping active Slack output.

Expiry establishes eligibility; cleanup runs remove qualifying records

An expiry timestamp defines when a record stops being usable or becomes eligible for cleanup. The scheduled sweep performs the relevant removal or content-expiry work. These stages should not be described as the same exact instant.

The current scheduling composition includes periodic cleanup of logs, completed work, expired thread context, parked links, reporting runs, raw draft content and other owned histories. Asset-trash cleanup is a separate scheduled job in that composition.

Bounded cleanup prevents one large category from demanding unbounded work in a single request. A record can be eligible while awaiting a subsequent batch or a successful run. The policy's typical period should not be turned into an exact second-level deletion guarantee.

Failed cleanup needs its actual outcome retained. A scheduled job existing in configuration is not proof that every run completed. Operational diagnostics can establish whether the relevant sweep succeeded or needs attention.

Routine sweeps and an individual verified data request are different processes. The former uses the category's normal cutoff. The latter needs its requested scope, identity and applicable handling. Do not pretend one routine cleanup result proves every record in a broader request was removed.

For the owner, the useful question is what stage is complete: expired from use, removed from the active view, scheduled for purge or permanently removed from the relevant service storage. Clear stages make the response reviewable.

The service copy and provider copies are separate

Google Ads, Merchant Center and Analytics hold their own provider data. ppctor reads supported information and can store relevant observations. Removing a service record does not delete the underlying provider campaign, product or property.

Slack receives delivered messages and files. Its own workspace content lifecycle is distinct from ppctor's context and operational stores. Expiring local thread context does not make a previously delivered Slack reply disappear.

AI inference can involve relevant questions, context and necessary account data sent to the configured provider. The current policy names those processors and explains the processing categories. The service's ninety-day log period is not a blanket statement about every provider's own records.

OAuth credentials are handled by the application and are not ordinary model input under the current policy. That credential boundary is separate from the business data used to answer a question. Review both when assessing the workflow.

An exported CSV or downloaded report can create another copy controlled by its recipient. The service cannot infer that every local copy disappeared because the source report was removed. The organization should manage its own shared exports appropriately.

For a removal plan, name which copy is involved and which party controls it. Service records, delivered workspace content and provider account data need different controls. Clear ownership prevents a deletion confirmation from being interpreted more broadly than the verified action.

Revocation stops access without automatically deleting saved information

Review the ppctor grant under Google Account permissions when the intention is to remove Google authorization. Google's connection-management guidance distinguishes app access and retained app data.

Removing the relevant access prevents new authorized provider use through that grant once the change takes effect. It is not the same as deleting the current app session or unlinking one selected property.

Google's revocation documentation explains the effect on issued credentials and combined granted authorization. A shared grant can affect more than one Google service. Decide whether that is the intended scope.

Previously saved audits, settings, results and delivered messages remain separate retained-information questions. The current privacy policy explicitly makes that distinction. A revoked grant does not rewrite an old report or erase an exported file.

If the intention is to stop one scheduled output, use its actual feature configuration or relevant integration control. If the intention is broader removal, state that request separately. Choosing the wrong layer can leave the real objective incomplete.

Document the final state and its evidence. A verified provider revocation, a disconnected destination and a completed retained-record removal are three distinct outcomes. The handover should name which ones were requested and completed.

Make a specific retained-data request

Use the privacy contact in the current policy when requesting access, clarification or removal of retained information. Identify the relevant business context and record category using safe descriptions. The service may need to verify identity before releasing or deleting account data.

State the intended outcome. For example: stop a scheduled report, remove the saved configuration, review retained conversation records or request account-data deletion. These examples describe different tasks and should not be collapsed into a vague instruction to disconnect.

Include enough timing and feature context to locate the relevant records. An approximate conversation date or saved report name can be useful. Raw tokens, session cookies and unrelated customer details are unnecessary.

Ask the response to distinguish completed actions from retained categories that require further handling. A partial removal should not be reported as deletion of everything. The answer needs to match the requested scope and actual evidence.

If ongoing features would recreate information, identify them in the request. A scheduled report that remains enabled can produce new run records after an older record is removed. Stop future processing and remove prior records as separate tasks where needed.

Keep the request and result in the appropriate private reference. This gives the owner a clear record of the desired scope, identity verification and outcome without distributing sensitive account material through ordinary Slack conversation.

Work through three fictional retention questions

Imagine invented agency Moss Lane asking why an old Slack follow-up lacks context. The relevant stored thread messages have passed their seven-day expiry. The workspace may still display the original messages, but the app's normal context read no longer includes those expired records.

Moss Lane understands that the assistant's context and diagnostic conversation logs are different categories. It restates the relevant business question safely rather than assume ninety-day log retention means unlimited model memory.

Now consider fictional retailer Brook Shelf deleting an uploaded creative. The item leaves the active library and enters the thirty-day recovery lifecycle. Later scheduled purge processes qualifying records and unreferenced blobs. That is different from an immediate permanent deletion guarantee at the original click.

Brook Shelf also reviews report files previously delivered to Slack. Those copies need separate handling. Removing the library record does not establish that every recipient-controlled copy disappeared.

Finally, invented service business Larch Home ends a reporting project. The owner stops the schedule, disconnects Slack, revokes the Google grant and requests the intended retained-record removal. Each action addresses a distinct layer.

Larch Home records which configuration is stopped, which authorization was removed and which data request outcome was confirmed. These examples use invented businesses and illustrate the lifecycle without exposing real customer information or treating one disconnect as a universal delete.

Keep a retention reference that matches the actual workflow

List the records the organization uses: connections, context, logs, saved audits, schedules, uploaded material and relevant execution history. For each, note the purpose, typical period and responsible removal control.

Distinguish active configuration from historical evidence. A completed reporting run can expire while the saved schedule remains enabled. A disconnected destination can have a parked restoration record. These states matter to the next operator.

Record the selected provider relationships and output audience. A service deletion and a Slack-content action have different owners. The team should know where copies were delivered before assuming that one removal completes the whole plan.

Link the current privacy policy instead of preserve an outdated summary as the permanent authority. If a feature-specific question remains, request clarification for that category. Do not invent backup, processor or provider retention periods the current evidence does not establish.

Review the reference at account handover or when a new scheduled feature is enabled. Adding a report, Rule or export can create a new record lifecycle and audience. The earlier session-expiry note does not cover every later addition.

A useful final reference identifies what stops automatically, what needs scheduled cleanup and what requires an explicit verified request. That gives the owner a practical understanding of retention rather than a misleading single-number answer.

Map the end of a reporting project before removing anything

Start with the project's active behavior. List the reports, monitoring configurations and Rules the team deliberately enabled. Decide which should stop and which remain useful to the business. This prevents a retained-data request from accidentally leaving the same workflow active and generating new records after older ones are removed.

Next list saved user-created information separately. An audit reference, a report configuration and a structured draft can have continuing value even when one delivery destination changes. Ask the owner which records should remain, which should be removed and which require clarification. Do not infer that changing the Slack workspace authorizes deleting every saved business record.

Then identify delivered copies. A report posted to a client channel and a downloaded CSV can belong to different recipient contexts. Record where the material went and who controls those copies. Local service cleanup cannot prove that a recipient's independent file disappeared.

Record the provider-access decision next. If the project ends but the business continues another feature, revoking the shared Google grant can have a broader effect than intended. If all access should end, use that grant control explicitly. Keep the desired provider outcome separate from the list of historical records.

For each requested action, define the evidence that would establish completion. A disabled schedule establishes that configuration state. A disconnected destination establishes its returned connection outcome. A retained-record response needs the specific category and removal result. One successful action should not be used as evidence that all other rows in the plan are complete.

Keep unresolved operational outcomes visible. If a report delivery was ambiguous, the owner needs the relevant reconciliation before assuming no copy exists. If an edit result was uncertain, inspect current provider state rather than delete context and repeat the operation. Retention decisions should preserve the evidence needed to avoid an unnecessary duplicate.

Use readable descriptions in the project reference. The business account, feature name, intended destination and approximate dates normally identify the task well enough for the owner. Technical keys can be resolved internally. A handover full of raw account IDs or private customer information creates additional copies without making the retention decision clearer.

Finally, update the reference with the completed outcomes and remaining questions. Distinguish records removed from active use, records awaiting their normal purge lifecycle and categories covered by a verified request. This turns a broad project-ending instruction into a reviewable set of data and access decisions without promising one universal delete.

Frequently asked questions about retention

Does everything disappear after seven days?

No. Seven days applies to specific context, session and parked-link lifecycles. Ordinary logs normally use ninety days, while saved connections and user-created records have their own removal or retention rules.

Does proposal expiry delete every related record?

No. The fifteen-minute proposal expiry governs approval eligibility. It does not establish immediate physical deletion of all proposal or execution evidence. Current-state and operation records remain distinct.

Does logout revoke Google authorization?

No. It ends the current session. Background credentials and the provider grant have separate lifecycles. Use the relevant feature controls or Google Account permissions when stopping future provider access.

Does expiring app context remove the Slack thread?

No. Local conversation context and workspace messages are separate copies. Slack content needs its own handling under the workspace's process.

What should a removal confirmation say?

It should identify the requested record scope, the completed action and any remaining relevant categories. A confirmed disconnect should not be presented as proof that all prior service, Slack and provider copies were deleted.