preview
We're still working on this feature, but we'd love for you to try it out!
This feature is currently provided as part of a preview program pursuant to our pre-release policies.
When templates don't fit your needs, Create Your Own lets you build custom workflows. Use the drag-and-drop interface to chain actions from the actions catalog into automation that matches your process.
How to use this guide
This guide shows you how to build workflows using concepts and a complete example. Choose your learning path:
Learn core concepts first → Read Core concepts and Workflow patterns to understand the fundamentals, then apply them
Follow the example → Jump to Example walkthrough to build an EC2 auto-resize workflow step-by-step
Reference patterns → Use the Workflow patterns section as a quick reference when building your own workflows
Dica
New to workflows? Start with core concepts, then follow the example. The EC2 workflow demonstrates all key patterns in a real-world scenario.
Why build custom workflows?
Build your own workflow to:
- Implement unique business logic that templates don't support
- Integrate multiple systems beyond standard templates
- Handle complex decisions with conditional branching
- Match your team's process for approvals and notifications
Core concepts
Understand these fundamentals before you build:
Concept | What it does | Example |
|---|---|---|
Inputs and secrets | Parameters for credentials and configuration |
|
Actions catalog | Pre-built integrations (AWS, Slack, databases, APIs) | Drag |
Data flow | Pass outputs between steps |
|
Switches | Create different paths based on conditions |
|
Loops | Process lists or poll for completion | Use |
Approval gates | Pause for human decisions | Slack reactions before destructive operations |
Error handling | Catch failures and run cleanup | Try-catch patterns with rollback procedures |
Dica
Learn by doing: Each concept is demonstrated in the Example walkthrough below. You'll see inputs, switches, loops, and approval gates working together in a real workflow.
For detailed error handling patterns, see Best practices.
Quick start
Build your first workflow in five steps:
- Navigate to one.newrelic.com > All Capabilities > Workflow Automation and select Create Your Own
- Define parameters for credentials (from secrets manager:
${{ :secrets:keyName }}), configuration (regions, instance types), and runtime data (account IDs, alert IDs) - Drag actions from the catalog, connect them with
${{ .steps.stepName.outputs.field }}syntax to pass data - Insert switches for conditional branching, loops for processing lists or polling, approval gates for human decisions
- Run after each section to catch errors early, then start or schedule your workflow
Dica
Start with 3 steps, test thoroughly, then expand. A working 5-step workflow beats a broken 20-step workflow.
Key workflow patterns
Four essential patterns handle most automation scenarios. Each pattern is demonstrated in the Example walkthrough below.
Conditional branching with switches
Use switches when: Outcomes vary based on data (threshold checks, API responses, user decisions)
Key syntax:
- name: hasCompleted type: switch switch: - condition: "${{ .steps.waitForCompletion.outputs.automationExecutionStatus == 'Failed' }}" next: displayError - condition: "${{ .steps.waitForCompletion.outputs.automationExecutionStatus == 'Success' }}" next: displaySuccess next: displayUnexpected # Default path when no condition matchesSee it in action: Handle team response and Verify and clean up sections show switches routing based on Slack reactions and AWS SSM status.
Loops for processing lists
Use loops when: Processing multiple items or repeating actions
Key syntax:
# Send progress updates using range loop- name: progressLoop type: loop for: in: "${{ [range(1; 5)] }}" # Loop 5 times steps: - name: wait type: wait seconds: 10 - name: progressMessage type: action action: slack.chat.postMessage version: 1 inputs: channel: "${{ .workflowInputs.channel }}" text: "Resizing in progress..."See it in action: Execute the resize section uses progressLoop for status updates.
Approval gates and waiting
Use approval gates when: Human judgment needed before destructive operations or compliance sign-off required
Key syntax:
- name: requestApproval type: action action: slack.chat.postMessage version: 1 inputs: channel: "#approvals" text: "Approve? React with :thumbsup: or :thumbsdown:"
- name: getReactions type: action action: slack.chat.getReactions version: 1 inputs: token: "${{ .workflowInputs.slackToken }}" channelID: "${{ .steps.requestApproval.outputs.channelID }}" threadTs: "${{ .steps.requestApproval.outputs.threadTs }}" timeout: 300 # Wait 5 minutes for reaction
- name: checkApproval type: switch switch: - condition: '${{ .steps.getReactions.outputs.reactions | any(.name == "+1") }}' next: handleApproval - condition: '${{ .steps.getReactions.outputs.reactions | any(.name == "-1") }}' next: handleRejectionFor simple delays:
- name: waitBeforeRetry type: wait seconds: 60 # Wait 60 seconds before continuingSee it in action: Request team approval section implements full Slack approval workflow.
Passing data between steps
Use data passing when: One step's output becomes another's input (the foundation of all workflows)
Key syntax:
# Reference previous step outputsawsRegion: "${{ .inputs.region }}"instanceId: "${{ .steps.getAlert.outputs.data.entity.instanceId }}"See it in action: All sections demonstrate data passing—each step builds on previous results.
Dica
Want complete pattern examples? See Workflow examples for additional patterns including error handling, retries, and complex integrations.
Example walkthrough: Auto-resize EC2 with approval
This complete example demonstrates how to build a workflow that automatically resizes EC2 instances when CPU spikes—after getting team approval via Slack. It shows data gathering, conditional logic, external integrations, and error handling in a real-world scenario.
Dica
New to workflows? This example uses AWS, Slack, and approval logic. Try Send report to Slack first if you're just starting.
Prerequisites
Before building this workflow, ensure you have:
- AWS: Credentials with EC2 and Systems Manager permissions
- Slack: Bot token and channel for notifications
- New Relic: Alert condition monitoring EC2 CPU
- Secrets manager: Configured (see secrets management)
Workflow overview
High-level flow:
- Gather data: Fetch alert and instance details from New Relic
- Request approval: Send Slack message, wait for team response
- Execute resize: Use AWS Systems Manager to resize EC2 instance
- Verify and clean up: Check results, notify team, remove temporary resources
This example demonstrates key patterns you'll use in custom workflows: querying APIs, conditional branching, external integrations, polling loops, and error handling.
Workflow inputs
Dica
Skip if you're reading for concepts. This table details the 12 parameters this workflow uses. You can reference it when building, but it's not essential for understanding the flow.
This workflow requires credentials, configuration, and runtime context as inputs. Sensitive values come from secrets manager using ${{ :secrets:keyName }} syntax.
Input categories:
- Authentication: AWS and Slack credentials from secrets manager
- Alert context: Account ID and issue ID from New Relic
- Configuration: Region, instance type, timezone, Slack channel
Build the workflow step-by-step
Now let's build each part of the workflow. Each step includes the specific actions to add and the workflow patterns they demonstrate.
Gather alert context
Query APIs and databases before taking action. This ensures you have complete context.
The workflow collects alert and EC2 instance information using three actions:
getAlertDetails: Calls NerdGraph API (New Relic's GraphQL API) to fetch alert metadata—activation time, condition name, and affected entities.activatedDateTime: Converts the timestamp to readable format like "01-24-2025 14:30" for Slack messages.impactedEC2Instance: Queries NRDB (New Relic database) to find the EC2 instance ID and current type.
Why this matters: Without these details, you can't construct meaningful Slack messages or target the right EC2 instance.
Request team approval
Connect to collaboration tools like Slack, PagerDuty, or ServiceNow for human decision points.
The workflow sends details to Slack and waits for a response:
IssueDetected: Posts alert details, current instance type, and proposed resize to Slack. Asks team to react with:+1:(approve) or:-1:(cancel).GetUserReaction: Pauses for 5 minutes (300 seconds) waiting for a reaction.checkQuery(Switch): Routes based on reaction:Dica
Common issue: Use Slack channel ID (
C01234ABCD), not channel name. Find it in Slack's channel details. See troubleshooting for more.
Handle team response
Use switches to create different paths based on data values or user input.
The workflow branches based on the reaction:
unexpectedReaction: Explains valid reactions and loops back to wait again.gotCancelReaction: Confirms cancellation, skips to completion. No infrastructure changes.gotYesReaction: Confirms approval, proceeds to resize.Dica
Approval gates pattern: Use switches like this when you need human judgment before risky changes. The pattern works with Slack reactions, PagerDuty acknowledgments, email responses, or custom webhooks.
Execute the resize
Use unique tokens to prevent duplicate operations. Use loops to check status of long-running operations.
The workflow resizes the instance through AWS Systems Manager (SSM):
createSsmDocument: Creates an SSM Automation document that stops the instance, modifies type, and restarts it.generateIdempotencyToken: Creates a unique UUID. Prevents duplicate resizes if the workflow runs twice.startResizing: Executes the SSM document with instance ID and new type.progressLoop(Loop): Posts Slack updates every 10 seconds (5 times total).waitForCompletion: Polls SSM status with 2-minute timeout.Importante
Why SSM? Systems Manager provides error handling, state verification, and CloudTrail audit logs. Better than direct EC2 API calls.
Dica
Common issue: Ensure AWS credentials have
ec2:StopInstances,ec2:ModifyInstanceAttribute,ec2:StartInstances, andssm:*permissions. Missing permissions fail silently.
Verify and clean up
Plan for failures and clean up temporary resources regardless of outcome.
The workflow checks results and removes temporary resources:
hasCompleted(Switch): Branches on SSM status (success/failed/timeout).displaySuccess: Logs success to New Relic.sendSuccessMessage: Confirms completion in Slack.displayError: Logs error details for troubleshooting.displayUnexpected: Logs unusual states (manual cancellation, etc.).cleanupSsmDocument: Deletes temporary SSM document.sendSSMCleanMessage: Confirms cleanup in Slack.workflowCompleted: Final completion message (runs for success or cancel).Dica
- Always clean up. Structure workflows so cleanup runs even when earlier steps fail. This prevents resource leaks and unexpected AWS charges.
- Common issue: If SSM times out, the EC2 instance may still be transitioning between states. Check AWS Console to verify actual instance status before re-running.
Next steps
Run and manage
- Start and schedule workflows: Trigger manually or schedule automatically.
- Managing workflows: Edit, version, clone, or deactivate workflows.
Improve
- Best practices: Error handling, secrets management, performance, testing.
- Actions catalog: AWS, Azure, GCP, HTTP, data transformations.
- Workflow examples: More real-world automation scenarios.
Scale
- Workflow Automation APIs: Deploy via API for infrastructure-as-code.
- Workflow limits: Timeouts, action limits, payload constraints.
