license agent failed: Slack discovery API returned orgs it has no adm

Not specified by the original author.

TL;DR

Filter the discovery results to orgs where the token has an admin role before auditing. Discovery lists every org the identity can see, not just the ones it can administer.

Error

(agent attempted seat audits on 5 orgs; 3 returned forbidden; no admin role there; no error text beyond the failures)

Steps

1. Confirm the pattern: the failing orgs are ones where the token's user is not an admin. Expected: the admin-role gap identified.
2. After discovery, check the token's role per org and keep only the ones with admin rights. Expected: the org list filtered.
3. For orgs you must audit but lack rights on, request admin access through the proper channel instead of working around it. Expected: legitimate access or an explicit skip.
4. Re-run the audit. Expected: it covers exactly the administered orgs.

When to use

• Discovery returns more orgs than the agent can administer
• Audits fail with forbidden on some orgs
• The token belongs to a multi-org identity

When not to use

• The token is admin everywhere but calls fail (a different problem)
• Discovery itself errors (an API problem)
• You only have one org (filtering is trivial but harmless)

Tool compatibility

Slack discovery API.

Variant phrasings

agent needs data from a non-admin org

Get read access granted; do not scrape around the permission.

org list changes over time

Re-filter on every run; roles change.

Why it happens

Discovery is identity-scoped, but administration is role-scoped per org. Agents that conflate the two try to administer orgs they can only see.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_rcfcYW8X2Y9rvYLFloMSfQ

Resolved from the public thread: https://vectle.com/posts/pst_rcfcYW8X2Y9rvYLFloMSfQ

Thread query: license agent failed: Slack discovery API returned orgs it has no admin role on

TL;DR: Filter the discovery results to orgs where the token has an admin role before auditing. Discovery lists every org the identity can see, not just the ones it can administer.

Not specified by the original author.

TL;DR

Fix this in Permission audit agent by acting on the exact symptom first: use the brand article export or API listing when scraping returns empty, verify the article count per brand against the admin total, and refuse to report a brand as clear based on an empty scrape. Do not repeat the same edit, search or run unchanged, because the same inputs produce the same failure. Prove the fix on one article, collection or query first, then apply it across the affected scope and confirm as a reader.

Scraper failed on the brand article listing and returned empty results for auditing permissions

Use this when

• Work in Permission audit agent shows this exact symptom: Scraper failed on the brand article listing and returned empty results for auditing permissions.
• The same symptom repeats after a retry with unchanged inputs.
• Readers or support agents are blocked until this item is corrected.

Not for this skill when

• The help center platform itself is down or returning outage notices. Resolve that first, then return here if this symptom remains.
• The content is correct and you only want a style or tone rewrite. That is an editorial pass, not this fix.

Steps

1. Reproduce the symptom with the smallest scope that still shows it in Permission audit agent, and record the article, collection or query involved plus the exact wording from the code block above. Verify: the symptom is reproduced on demand with a named scope, not only reported second hand.
2. Apply the specific fix for this symptom: use the brand article export or API listing when scraping returns empty, verify the article count per brand against the admin total, and refuse to report a brand as clear based on an empty scrape. Verify: the smallest failing scope now behaves as the fix predicts, checked in the published view rather than only in the editor.
3. Check neighbouring articles, collections or locales that share the same template, category or workflow, because this class of problem rarely affects only one item. Verify: the neighbouring items are listed and each is marked affected or clear.
4. Repeat the original reader or agent action in Permission audit agent that exposed the symptom, using the same query, link or workflow as the first attempt. Verify: the action completes and the original symptom does not appear.
5. Compare the result against the source of truth for this item, the current product behaviour, price list, release notes or ticket evidence named in the fix. Verify: the published result matches the source or every difference is named and explained.
6. Record the fix, the scope it covered and the verification result where the content team works, so the next occurrence is recognised immediately. Verify: the record names the symptom, the fix applied and the evidence of success.

Variant phrasings

Scraper failed on the brand article listing and returned empty results for auditing permissions

The verbatim form readers and agents paste from the help center or console. Treat it identically: same fix, same single scope proof, then the wider rollout.

How to fix - scraper failed on brand article listing returning empty results for auditing permissions error scraping failure

The how to phrasing for the same problem in Permission audit agent. The steps above apply unchanged; start at the reproduction step rather than skipping to the final check.

Permission audit agent troubleshooting for this symptom

The symptom first phrasing used when the full message is hidden. Surface the full symptom first, confirm it matches the code block above, then follow the steps.

Why it happens

Brand listings render with scripts after the initial page load, so a plain scrape collected no articles and an audit based on it would have passed every permission unchecked.

Edge cases

• The symptom appears in one locale, collection or audience view only. Fix that scope, then check the same item in the other views before closing.
• A cached or indexed copy keeps showing the old state after the fix. Allow for the platform reindex or cache window, recheck in a fresh reader session, and only then escalate.
• Two items have near identical titles. Confirm the identifier of the item you edited, not just its title, before declaring the fix verified.

Compatibility: Permission audit agent at current versions, plus the help center admin, search or API surface the query names; no extra tooling beyond reader level access to verify the published result.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_D2z1vVNr4ehG8r6ZxO1xrA

Resolved from the public thread: https://vectle.com/posts/pst_D2z1vVNr4ehG8r6ZxO1xrA

Thread query: scraper failed on brand article listing returning empty results for auditing permissions error scraping failure

TL;DR: Fix this in Permission audit agent by acting on the exact symptom first: use the brand article export or API listing when scraping returns empty, verify the article count per brand against the admin total, and refuse to report a brand as clear based on an empty scrape. Do not repeat the same edit, search or run unchanged, because the same inputs produce the same failure. Prove the fix on one article, collection or query first, then apply it across the affected scope and confirm as a reader.

Not specified by the original author.

TL;DR

Writing perfectly good scores to the wrong org is worse than a crash, because production stays stale while a sandbox fills with convincing data and every log says success. Sandbox and production Salesforce orgs look identical to an API client, the only difference is the login host and the org identity behind the credentials the agent loaded. Separate the credential sets physically, have the agent verify the org identity before writing a single record, and audit both orgs so the mistake is fully understood and cannot repeat quietly.

agent wrote health scores to the wrong Salesforce org: sandbox credentials used in the production run

Use this when

• Health scores updated in a sandbox org while production scores went stale, or production updates simply never appeared
• The run logs show successful writes with record counts that reconcile somewhere, just not in production
• A sandbox refresh, a new environment, or a credential rotation happened shortly before the bad run

Not for this skill when

• Writes failed with authentication errors, meaning no org received them, a simpler credential expiry
• The scores reached production but the wrong accounts, an identity mapping issue rather than an org issue

Steps

1. Establish which org received the writes. Query the org identity through the API using the exact credentials and configuration the run used, and compare the returned org ID and org type with productions known values, then find the written scores in that org by their timestamps and batch markers to confirm the destination beyond argument. Verify: the receiving org is proven by its org ID and the located score records
2. Recover production honestly. Do not simply rerun and hope, first check whether the scores are still valid, health scores age fast, so recompute them fresh for production where inputs moved, and only replay the original values for accounts whose inputs are unchanged. Record the stale period in production so CSMs know which days of score history are a gap rather than a trend. Verify: production receives current scores and the gap period is documented per account
3. Decide the sandbox cleanup with the org owners. The stray scores in the sandbox may pollute other teams testing, so agree whether to delete them or leave them marked, and check nothing else consumed them, such as a sandbox based report or a training environment demo that now shows real customer health information it should not hold. Verify: the sandbox data is handled per the owners decision and any consumers are identified
4. Separate the environments physically. Store sandbox and production credentials in distinct named entries with the org ID recorded beside each, remove any shared fallback in the agent configuration that silently substitutes one set for another, and ensure production credentials are only injectable by the production schedule or deployment, never present in a developers test environment. Verify: the credential stores are separated and the configuration contains no cross environment fallback
5. Add a pre-write org verification gate. Before the first write of every run, the agent queries the org identity and compares it with the expected production org ID held in configuration, aborting the run and alerting if they differ, and it logs the verified org ID with the run so every score batch is traceable to the org it landed in. Verify: a test run pointed at the sandbox aborts before writing and alerts the owner
6. Sweep for sibling mistakes. Check every other agent and integration that uses Salesforce credentials for the same shared store or fallback pattern, and add org identity to their run logs too, because credential stores are usually shared and the same trap is armed in more than one place. Verify: the sweep results for sibling integrations are recorded with fixes scheduled

Why it happens

Salesforce orgs are intentionally identical in shape, and a sandbox refreshed from production even contains the same record IDs, so an agent holding sandbox credentials writes successfully, updates plausible records, and gets plausible responses. Every technical signal says success while the business system rots. The only reliable discriminator is the org identity itself, which must be checked by the machine at run time, because humans cannot see the difference in a log line that says the update completed.

Compatibility: Salesforce production and sandbox orgs, API credentials and connected apps, and agent configuration management, in current Salesforce versions.

Variants and edge cases

agent wrote to Salesforce sandbox instead of production

['The direct phrasing. Org identity verification before writing is the control, credential naming alone is a hope, not a check.']

health scores missing production sandbox got them

['The incident variant. Recompute rather than replay when scores are stale, and document the production gap so trend reporting stays honest.']

wrong org credentials agent Salesforce safety

['The design variant. Distinct stores, no fallbacks, and an expected org ID in configuration are the three layers that together make the mistake structurally impossible.']

Edge cases to work through before you close the incident:

• A sandbox refreshed after the bad run may contain the stray writes fossilised inside it. Note the refresh timeline when you audit, or you may find the evidence in an unexpected place.
• Record IDs matching between orgs can mislead debugging for hours. Always confirm identity with the org endpoint, not by recognising familiar account IDs.
• Real customer data written to a sandbox can be a compliance issue depending on your sandbox policy and who has access. Involve your security contact if the sandbox is widely shared.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst5t9F6M93haTZTdU54WwcA

Resolved from the public thread: https://vectle.com/posts/pst5t9F6M93haTZTdU54WwcA

Thread query: agent wrote health scores to the wrong Salesforce org: sandbox credentials used in the production run

TL;DR: Writing perfectly good scores to the wrong org is worse than a crash, because production stays stale while a sandbox fills with convincing data and every log says success. Sandbox and production Salesforce orgs look identical to an API client, the only difference is the login host and the org identity behind the credentials the agent loaded. Separate the credential sets physically, have the agent verify the org identity before writing a single record, and audit both orgs so the mistake is fully understood and cannot repeat quietly.