sentinel-one/ai-siem/sdl-solutions

SentinelOne SDL Solutions

<!-- CONFIG-FILE-ADDRESSING v1 -->

SDL config files: address by `udoId`, and do not trust a REST listing.

REST listFiles / getFile cannot see udoId-addressed /dashboards/ files, so getFile

returns 404 on a dashboard the console is displaying and the listing under-reports (measured on

one tenant: REST 8, GraphQL 17, console 48 files). **If a listing disagrees with what the UI

shows, the listing is wrong until proven otherwise**, change read path before concluding the

object is missing or the token lacks scope. Use the GraphQL configFiles / configFile surface.

A name-addressed addConfigFile to /dashboards/ creates a duplicate instead of updating;

address dashboards by udoId with expectedVersion. content is HJSON, not JSON. S1-Scope

changes which files exist as far as the caller can tell.

Full detail: `sdl-api/references/config-file-graphql.md`

This skill packages repeatable SDL solutions and deploys them into a specific customer environment from a short set of prompts. It is an orchestration layer: it does not reimplement PowerQuery, parser, SDL API, or Hyperautomation mechanics. Instead it collects the customer parameters, renders the solution's templates, previews the result, deploys through the primitive skills, and validates.

Use this skill when the user wants to deploy or tailor a whole solution. For a single query, parser, dashboard, or workflow, use the matching primitive skill directly.

Solution catalog

More solutions are added under references/<solution>.md plus templates under assets/. See "Adding a new solution" below.

How a deployment runs (always follow this loop)

1. Pick the solution. If the user named it, use it. Otherwise show the catalog and ask which one.
2. Collect parameters with simple prompts. Ask only what the playbook needs, one compact question set, with sensible defaults pre-filled. Never start deploying before parameters are confirmed. Each playbook lists its parameters and defaults.
3. Confirm the environment. Resolve the target site name to a siteId (fuzzy match, console site names can contain spaces). Confirm the console/tenant. Read existing config versions before any overwrite.
4. Render and preview. Fill the templates in assets/ with the parameters and show the user the final config (queries, parser, workflow) and the projected enriched record BEFORE deploying. This is a dry run.
5. Deploy in dependency order through the primitive skills (see each playbook for the exact order). Typical order: build lookup tables, then parser or lookup guidance, then refresh flow.
6. Validate with a real ingest and query, and report what populated. Use metadata.version as the propagation canary for parser changes.
7. Test end to end with run-now, then prompt the user. For any solution with HA flows, trigger each flow immediately with POST /web/api/v2.1/hyper-automate/api/public/workflow-execution/manual/{id}/{version}?accountIds=<acct> (works on scheduled-trigger flows once active), poll GET .../workflow-execution/{exec_id} until state is Completed with error_actions: [] and executed_actions == the action count, and confirm the downstream effect (tables written, dashboard renders, a detection alert present). An import is NOT complete until the flow is published to a Shared Draft: treat ha_import_workflow and publish as ONE atomic step, publish in the SAME step as the import, never as a follow-up. Imported flows land as PRIVATE DRAFTS owned by the API token's user (invisible in the console to the person who asked), so IMMEDIATELY after each ha_import_workflow publish it to a Shared Draft: POST /web/api/v2.1/hyper-automate/api/v1/workflows/{id}/publish?siteIds=<id> (bodyless {}, returns 204; use accountIds=<acct> for account-scoped flows). A published flow stays inactive until its connection is bound and it is activated, so always end a deployment by prompting the user to bind/activate and run this E2E check (offer to run it for them once active).
8. Summarize the deployed artifacts (paths, IDs, site) and hand off the rendered config files.