mirror of
https://github.com/forcedotcom/afv-library.git
synced 2026-08-07 16:04:41 +08:00
20ae436442
Data Cloud 360° view of a single Agentforce session — DC-only, zero
Splunk dependency. Pulls 24 STDM + GenAI DMOs via the Data Cloud Query
REST API, assembles a hierarchical session tree (Interaction → Step →
Generation → GatewayRequest), and renders a human-readable markdown
summary with transcript + per-turn topic/action invocations + LLM
generations + tool calls + audit chain.
Migrated as a standalone Apache-2.0 skill from an internal hub plugin —
self-contained, no sibling-skill or plugin dependencies.
What this skill answers:
- "Trace session <uuid>" / "Summarize what happened in <0Mw…>"
- "Find escalated sessions today on Messaging in <org>"
- Session discovery by time / agent / channel / outcome / conversation
text when the user has no session id
What it does NOT answer (use a different surface):
- Design-time architecture — use investigating-agentforce-architecture
- Runtime planner availability — DC alone can't tell you which
topic/action was eligible for the classifier on a given turn
Skill layout:
- 8 Python pipeline modules (fetch_dc, assemble_dc, render_dc,
discover_sessions, resolve_session, dc, storage, config)
- 4 _shared helpers (paths, fs_guard, sql, __init__) with skill-scoped
DATA_ROOT (~/.claude/data/investigating-agentforce-d360/)
- 26 SQL templates under assets/dc/
- 27 test files (367 tests + 18 subtests, 100% passing)
- 3 reference docs (artifacts.md, dc_dmo_fields.md,
dc_pipeline_contract.md)
- SKILL.md (sf-skills frontmatter, license: Apache-2.0,
metadata.version: "1.0")
- README.md (external-facing quick-start)
- tools/grant_allowlist.py (idempotent first-run permission grant)
- tools/archive_data_dir.sh (opt-in stop-hook tarballer)
Quality gates:
- pytest scripts/tests/: 367 passed + 18 subtests, 0 failures
- npm run validate:skills: 62 of 62 skill(s) checked, 0 errors
- Live end-to-end runs against 3 real Salesforce sessions exercising
both the full-tree and STDM-lag gateway-direct render branches
- 4 independent code-review rounds (correctness, security, markdown,
architecture-critic) — all findings addressed
Customer-data hygiene: no live tenant ids, no internal sprint markers,
no hub/sibling-skill references. Synthetic fixtures look obviously
synthetic (`019dface-…` UUIDs, `0MwTESTMSG…` MessagingSession ids,
`00DTESTORG…` org ids, `MyAgent` placeholder agent name).
Sibling skill: investigating-agentforce-architecture (PR #278) — same
migration pattern, design-time metadata; complementary scope.
52 lines
1.9 KiB
SQL
52 lines
1.9 KiB
SQL
-- App-layer generation records — reusable for any WHERE filter.
|
|
-- DMO: GenAIAppGeneration__dlm
|
|
--
|
|
-- Placeholders (substituted by scripts/dc.py.load_sql):
|
|
-- WHERE_CLAUSE — the filter expression, no "WHERE" keyword
|
|
-- ORDER_BY — full "ORDER BY <col>" or empty string
|
|
--
|
|
-- Sibling of GenAIGeneration__dlm: where GenAIGeneration is the raw
|
|
-- gateway response, GenAIAppGeneration appears to be the app/feature-
|
|
-- layer view of the same generation (separate `id__c` from `generationId__c`).
|
|
--
|
|
-- No `ssot__` prefix — fields end in `__c` directly.
|
|
--
|
|
-- Join to a session: the same Step → Generation bridge used for
|
|
-- GenAIGeneration also works here. Pull session steps, collect
|
|
-- non-empty `ssot__GenerationId__c` values, then query here with
|
|
-- `generationId__c IN (...)`. The App-Generation row points at the
|
|
-- same underlying gateway generation.
|
|
--
|
|
-- The DMO is provisioned by default on orgs with generative AI audit
|
|
-- enabled, but row population depends on whether the org uses app-layer
|
|
-- regeneration / update flows. Verify presence with `sf ssot/metadata`
|
|
-- before relying on it.
|
|
|
|
SELECT
|
|
id__c,
|
|
generationId__c,
|
|
generationUpdate__c,
|
|
generationUpdateId__c,
|
|
feature__c,
|
|
timestamp__c,
|
|
orgId__c,
|
|
cloud__c
|
|
FROM GenAIAppGeneration__dlm
|
|
WHERE {{WHERE_CLAUSE}}
|
|
{{ORDER_BY}};
|
|
|
|
|
|
-- ============================================================================
|
|
-- EXAMPLE WHERE clauses (pass via where_clause=)
|
|
-- ============================================================================
|
|
|
|
-- App-generations for a set of step generation ids
|
|
-- WHERE → generationId__c IN ('<gen_id1>','<gen_id2>',...)
|
|
-- ORDER BY → ORDER BY timestamp__c
|
|
|
|
-- App-generations in a time window for one org
|
|
-- WHERE → orgId__c = '<org_id_18>'
|
|
-- AND timestamp__c >= '<iso_window_start>'
|
|
-- AND timestamp__c < '<iso_window_end>'
|
|
-- ORDER BY → ORDER BY timestamp__c
|