Content Development: Playbooks, Scripts, and Integrations
This domain tests whether you can build and ship playbooks, scripts, and integrations that behave predictably inside a content pack, including the packaging and versioning rules the platform enforces.
Playbooks
- A playbook is YAML with a start task id, a tasks map, and typed tasks: start, regular, condition, title, collection, and sub-playbook.
- Conditions branch on context values; parallel branches come from giving one task several next-task entries.
- Task inputs and outputs are declared on the playbook, which is what surfaces data for reuse and for the layout.
Integrations and scripts
- An integration is a YAML definition plus Python code, with common fields, configuration, and script sections. Each command name maps to a function that receives arguments and returns results.
- Use
return_results()withCommandResultsfor Python 3;demisto.results()is legacy and loses typed outputs. - Context keys are case-sensitive, and a command's declared outputs must match what the code returns, or playbooks see nothing.
- Pin the Docker image and declare a realistic minimum server version so the pack installs where it is supported.
Worked example
A script must return a reputation verdict for an IP. Reasoning: read the argument with demisto.args(), call the lookups with demisto.executeCommand(), build a CommandResults with an outputs payload and a dbotScore entry, and return it with return_results(). Wrap failures in return_error() so the task fails visibly rather than silently.
Traps
Editing built-in content instead of a custom copy, omitting release notes and pack metadata, and testing only in the War Room where the command line hides missing output declarations.