⬡ Module 01 · Introduction

Event Pipelines
in Delinea Secret Server

Learn to automate PAM workflows by wiring event triggers to automated actions — no code required.

What Are Event Pipelines?

Event Pipelines in Delinea Secret Server enable automated, policy-driven workflows that respond to events occurring within your PAM environment. When a defined event fires — such as a secret being checked out, a password expiring, or a user being added — the pipeline executes a series of configured tasks automatically.

This removes the need for manual intervention in routine security and compliance operations, reducing human error while improving auditability.

▸ Pipeline Architecture

⚡ Trigger EVENT SOURCE

→

⧩ Filter CONDITION

→

⚙ Task OPERATION

→

↗ Action OUTCOME

Core Concepts

⚡

Trigger Events

Any auditable action in Secret Server can be a trigger — secret access, expiration, heartbeat, permission changes, and more.

⧩

Pipeline Filters

Conditions that must be true for the pipeline to proceed. Stack multiple filters with AND/OR logic for precision targeting.

⚙

Tasks

Discrete units of work — from sending an email to running a custom script or changing a secret's permission group.

📋

Pipeline Policies

Rules that bundle pipelines and apply them to secrets at the folder or template level, enabling inheritance.

🔄

Run-as Account

A service account that executes pipeline tasks. Must have sufficient permissions for all intended operations.

📊

Audit Trail

Every pipeline execution is logged with full context — trigger time, result, and any error details.

Common Use Cases

Scenario	Trigger	Action	Benefit
Notify on privileged checkout	Secret View	Send Email	Visibility
Auto-rotate on breach	Heartbeat Failure	Remote Password Change	Security
Ticket on expiry warning	Days Until Expiry	ServiceNow Webhook	Compliance
Restrict access after hours	Access Request	Run Script (deny)	Policy
Slack alert on failed login	User Login Failure	HTTP Post	Monitoring

⬡ Module 02 · Setup

Prerequisites & Access

Ensure your environment and permissions are configured before building your first pipeline.

Required Permissions

To create and manage event pipelines, your account or role must have the following permissions enabled in Secret Server:

Permission	Location	Required For
Administer Event Pipeline Policy	Role permissions	Creating/editing pipelines
View Event Pipeline Policy	Role permissions	Viewing pipeline configs
Administer Scripts	Role permissions	Script-based tasks
Administer Run As Service Account	Role permissions	Pipeline execution account

⚠

Minimum Role: Administrator Standard User roles cannot configure event pipelines. You must be assigned a role with Administer Event Pipeline Policy explicitly checked.

Pre-Flight Checklist

Click each item to mark it complete before proceeding.

Confirm you have Admin or equivalent role in Secret Server

Identify a dedicated Run As service account (a local SS user or AD account)

Verify SMTP is configured if using email-based actions (Admin → Configuration → Email)

Confirm outbound HTTP allowed if using webhook tasks (check firewall rules)

Enable Event Pipelines feature flag: Admin → Configuration → General → Enable Event Pipelines

Document the target secrets / folders / templates this pipeline will apply to

Enabling the Feature

1

Navigate to Configuration

Go to Admin → Configuration from the top navigation bar. You must be a Secret Server Administrator.

2

Open the General Tab

Select the General tab and scroll to the User Experience section.

3

Enable Event Pipelines

Check "Enable Event Pipeline Policy" and click Save Changes. The Event Pipelines menu will now appear under Admin.

💡

Pro Tip: Dedicated Run-As Account Create a dedicated Secret Server local user (e.g., svc_pipeline_runner) with only the permissions needed for your pipeline tasks. This limits blast radius if credentials are compromised and keeps your audit logs clean.

⬡ Module 03 · Setup

Creating Your First Pipeline

Navigate the Event Pipeline interface and create a pipeline definition from scratch.

Accessing Event Pipelines

From the Secret Server navigation: Admin → Event Pipeline Policy. You'll see a list of all existing pipelines and policies in your environment.

ℹ

Two-Part Structure In Delinea, you first create a Pipeline (the trigger + tasks logic), then assign it to a Policy (which secrets/folders it applies to). Pipelines are reusable across multiple policies.

Step-by-Step: New Pipeline

1

Click "Add New Pipeline"

On the Event Pipeline Policy page, click the + Add New Pipeline button at the top right of the Pipelines list.

2

Name & Describe the Pipeline

Enter a clear, descriptive Name (e.g., "Notify CISO on Root Checkout") and an optional description explaining the business purpose. Good naming is critical for long-term maintainability.

3

Select the Trigger Event

Choose the event type that fires this pipeline from the Trigger dropdown. This is the most important decision — see Module 04 for full trigger reference.

4

Configure the Run-As Account

Select the service account under which pipeline tasks will execute. This account must have permissions to perform all the actions defined in the pipeline tasks.

5

Add Tasks (optional at creation)

Add one or more task definitions. You can save a pipeline with no tasks yet — useful for scaffolding. Tasks are covered in depth in Module 05.

6

Save as Draft

Click Save. The pipeline is saved in Draft status and will not execute until it is added to an active policy and the policy is activated.

Naming Conventions (Best Practice)

          Naming Pattern
          
        
[Trigger]_[Target]_[Action]_[Environment]

# Good examples:
SecretView_ProdDatabaseCreds_EmailCISO_PROD
HeartbeatFail_AllLinuxAccounts_RotatePassword_PROD
DaysUntilExpiry_ServiceAccounts_CreateTicket_STAGING

# Avoid:
Pipeline1          # ← Non-descriptive
test_pipeline      # ← Unclear purpose
emailAlert         # ← Missing context

⬡ Module 04 · Design

Triggers & Filters

Master every event trigger type and build precise filter conditions that reduce noise and increase accuracy.

Trigger Event Reference

Secret Server supports the following trigger categories. Each trigger fires the pipeline when the specified event occurs in the system.

Category	Trigger Event	When It Fires
Secret	Secret View	Any user views a secret's value
Secret	Secret Edit	Secret fields are modified
Secret	Secret Checkout	Secret checked out for exclusive access
Secret	Secret Check-In	Checked-out secret is returned
Secret	Secret Created	A new secret is created
Secret	Secret Deleted	A secret is soft-deleted
Password	Password Changed	Remote password change completes
Password	Heartbeat Failure	Heartbeat check fails (password mismatch)
Password	Days Until Expiry	N days before password expiry (configurable)
User	User Login	Successful user login
User	User Login Failure	Failed login attempt
Access	Access Request Created	User submits an access request
Access	Access Request Approved	Request is approved
Access	Access Request Denied	Request is denied

Understanding Pipeline Filters

Filters prevent pipelines from firing indiscriminately. Without filters, a Secret View trigger would fire for every single secret view in the entire system. Filters let you narrow scope precisely.

📁 Folder Filter

Restricts the pipeline to secrets located within a specified folder path. Supports Include Subfolders toggle for hierarchical matching.

📄 Template Filter

Limits the pipeline to secrets using a specific secret template (e.g., Windows Account, Unix Account Root, Database).

🏷 Secret Name Filter

Matches secrets whose names contain a pattern string. Case-insensitive. Use for targeting specific resource sets like "PROD-DB-*".

🌐 Site Filter

Filters by the Distributed Engine site the secret is assigned to. Critical in multi-site environments to avoid cross-region noise.

Filter Stacking Logic

ℹ

Filters use AND logic by default When multiple filters are added to a pipeline, all conditions must be true for the pipeline to proceed. Plan your filter stacks carefully to avoid over-restricting or under-restricting execution.

          Filter Logic Example
        
# This pipeline fires ONLY when ALL of these are true:

Trigger   = Secret View
AND Folder    = /Production/DatabaseServers (include subfolders)
AND Template  = SQL Server Account
AND Secret Name contains "sa-"

# Result: Fires only when a SQL SA account secret
# in the Production DB folder is viewed

⬡ Module 05 · Design

Tasks & Actions

Configure the operations your pipeline executes — from email notifications to script execution and webhook calls.

Available Task Types

📧

Send Email

Send templated emails to one or more recipients. Supports dynamic variables like secret name, user, and timestamp.

📡

HTTP / Webhook POST

Send a JSON payload to any HTTP endpoint. Use for Slack, Teams, ServiceNow, Jira, PagerDuty, or custom APIs.

⚙

Run Script

Execute a PowerShell, SQL, or SSH script stored in Secret Server's Script Library with the Run-As account.

🔑

Remote Password Change

Immediately rotate the password on the remote system associated with the secret.

👥

Change Group

Add or remove the secret from a secret policy group, modifying access control automatically.

⏸

Disable Secret

Immediately disable (deactivate) the secret, preventing further access without deleting it.

Configuring a Send Email Task

1

Add Task in Pipeline Builder

Inside your pipeline definition, click + Add Task and select Send Email from the task type dropdown.

2

Set Recipients

Enter email addresses in the To field. You can also use dynamic variables to email the secret's owner: $SECRET_OWNER_EMAIL

3

Craft Subject & Body with Variables

Use Secret Server's pipeline variable tokens in your email template. See variable reference below.

4

Set Failure Behavior

Choose whether pipeline should Stop on Failure or continue to next tasks if this task fails (e.g., SMTP is down).

Pipeline Variable Reference

          Available Variables
          
        
# Secret Context
$SECRET_NAME          # Display name of the secret
$SECRET_ID            # Numeric secret ID
$SECRET_FOLDER_PATH   # Full folder path
$SECRET_TEMPLATE_NAME # Template type name

# User Context
$USER_DISPLAY_NAME    # Name of the user who triggered the event
$USER_EMAIL           # Email of the triggering user
$USER_USERNAME        # Login username

# Event Context
$EVENT_TIME           # ISO timestamp of the event
$EVENT_TYPE           # The trigger event name
$SITE_NAME            # Distributed Engine site name

# Example email subject:
"[ALERT] $SECRET_NAME accessed by $USER_DISPLAY_NAME on $EVENT_TIME"

Configuring a Webhook Task

          Webhook / Slack Payload Example
          
        
{
  "text": "🔐 *Secret Alert*",
  "attachments": [{
    "color": "#ff6b35",
    "fields": [
      { "title": "Secret",    "value": "$SECRET_NAME",       "short": true },
      { "title": "Accessed By", "value": "$USER_DISPLAY_NAME", "short": true },
      { "title": "Folder",    "value": "$SECRET_FOLDER_PATH", "short": false },
      { "title": "Time",      "value": "$EVENT_TIME",         "short": true }
    ]
  }]
}

💡

Task Ordering Matters Tasks execute in the order listed. Put notification tasks early and destructive/disruptive tasks (like password rotation) last. Add a Wait task between tasks if the downstream system needs time to process.

⬡ Module 06 · Design

Pipeline Policies

Policies bind your pipeline logic to secrets — controlling scope, inheritance, and activation state.

Pipeline vs. Policy: The Distinction

Pipeline

Logic Definition

Contains the trigger, filters, and tasks. Reusable — one pipeline can be assigned to multiple policies. Created in Admin → Event Pipeline.

Policy

Scope & Assignment

Binds one or more pipelines to a set of secrets via folder assignment or direct secret assignment. Controls whether the pipeline is active.

Creating a Policy

1

Go to Admin → Event Pipeline Policy

Click the Policies tab (distinct from the Pipelines tab) and click + Add New Policy.

2

Name the Policy

Use a business-context name: "Production Database Secrets Monitoring". This appears in audit logs.

3

Add Pipelines to the Policy

Click + Add Pipeline and select from your saved pipeline definitions. Add as many as needed — they all execute when their triggers fire within this policy's scope.

4

Assign Scope (Folders or Secrets)

Under Applicable Secrets, assign the policy to specific folders (with optional subfolder inheritance) or individual secrets directly.

5

Set Policy Status to Active

Toggle the policy status to Active. Only active policies execute their pipelines. Leave as Inactive during testing phase.

Policy Inheritance Model

When a policy is assigned to a folder, all secrets within that folder (and subfolders if enabled) inherit the policy automatically. This is the recommended approach for broad coverage.

Inheritance Example
# Policy assigned to: /Production/DatabaseServers (include subfolders)

/Production/DatabaseServers/           ← Policy applies
/Production/DatabaseServers/MySQL/       ← Inherited ✓
/Production/DatabaseServers/Oracle/      ← Inherited ✓
/Production/DatabaseServers/Oracle/Prod/ ← Inherited ✓

/Production/WebServers/                  ← NOT covered (different branch)
/Staging/DatabaseServers/                ← NOT covered (different root)

⚠

Policy Conflicts If a secret is covered by multiple policies that contain conflicting pipelines, both will execute. Design policies with clear, non-overlapping folder scopes to avoid duplicate notifications or redundant actions.

⬡ Module 07 · Manage

Testing & Validation

Validate your pipeline logic before activating it in production — catch errors before they affect real operations.

Testing Strategy

🚫

Never test in Production first Always validate pipelines against non-production secrets or a dedicated test folder before assigning to production-scope policies. A misconfigured pipeline can trigger password rotations or disable secrets unexpectedly.

Test Checklist

Create a dedicated test folder: /Test/EventPipeline/ with dummy secrets

Build a test policy with the pipeline assigned to the test folder only

Activate the test policy and manually trigger the event (view, edit, or check out the test secret)

Verify the pipeline executed in Admin → Event Pipeline Runs (check status: Success / Error)

Confirm each task output: email received, webhook delivered, script ran with expected result

Test failure scenarios: disable SMTP or provide wrong webhook URL and confirm error behavior

Review audit log entries generated by the pipeline execution

Reading the Pipeline Run Log

Navigate to Admin → Event Pipeline Policy → Pipeline Runs to see execution history.

Column	Meaning
Pipeline Name	Which pipeline was executed
Trigger Event	The specific event that fired the pipeline
Secret	The secret involved in the trigger
User	The user whose action triggered the event
Start Time	When pipeline execution began
Status	Success, Running, Error, or Skipped (filter didn't match)
Details	Task-level execution details and any error messages

Common Errors & Fixes

❌ Run-As Auth Failure

The service account doesn't have permission for the task. Fix: Grant the Run-As account the necessary role permissions or folder access.

❌ SMTP Connection Failed

Email task can't reach the mail server. Fix: Verify Admin → Configuration → Email settings and check firewall rules for port 25/587.

❌ Webhook 401/403

HTTP task gets rejected. Fix: Add an auth header in the webhook task configuration with the API key or Bearer token.

⚠ Skipped (Filter Miss)

Pipeline triggered but filter conditions weren't met. Fix: Review your filter values — check exact folder paths and template names match.

⬡ Module 08 · Publish

Publishing & Activation

Safely promote your pipeline to production scope with a structured activation process.

Pre-Publication Checklist

All pipeline tasks tested successfully in staging environment

Run-As service account permissions confirmed for all tasks

Pipeline and policy names follow your organization's naming convention

Policy scope (folder assignment) reviewed and approved by team lead

Change management ticket filed (if required by your org's change process)

Notification recipients or webhook destinations confirmed as correct

Activation Steps

1

Update Policy Scope to Production

Edit the policy and change or add the production folder(s) in the Applicable Secrets section. Remove the test folder if it was only for testing.

2

Set Policy Status to Active

Toggle the policy status from Inactive to Active. This is the go-live moment — the pipeline will now execute for all future events within scope.

3

Perform a Controlled First-Fire Test

Immediately after activation, deliberately trigger the pipeline with a non-sensitive in-scope secret to confirm end-to-end execution in production.

4

Monitor for 24 Hours

Watch the Pipeline Runs log for the first day. Look for unexpected fire rates, errors, or false-positive triggers and tune filters if needed.

5

Document in Your Runbook

Add the pipeline's purpose, scope, Run-As account, and escalation path to your internal PAM runbook for team awareness.

💡

Rollback Plan To quickly disable a pipeline in production, simply set the policy Status → Inactive. This takes effect immediately with no restart required. The pipeline definition is preserved for re-activation.

Version Control Best Practice

Secret Server doesn't have native pipeline version history. Maintain your own documentation:

Pipeline Documentation Template
## Pipeline: SecretView_ProdDatabaseCreds_EmailCISO_PROD

Created:     2024-03-15  |  Last Modified: 2024-03-20
Owner:       security-team@company.com
Policy:      Production Database Secrets Monitoring
Trigger:     Secret View
Scope:       /Production/DatabaseServers (include subfolders)
Run-As:      svc_pipeline_runner
Tasks:
  1. Send Email → CISO distribution list
  2. POST Webhook → Slack #security-alerts

Business Purpose: Notify security team of any production
database credential access for compliance requirements.

Escalation:  security-oncall@company.com
Change Ticket: CHG0012345

⬡ Module 09 · Manage

Monitoring & Logs

Keep your pipelines healthy with proactive monitoring, log analysis, and maintenance routines.

Key Monitoring Locations

Location	Path in Secret Server	What to Check
Pipeline Runs	Admin → Event Pipeline Policy → Pipeline Runs	Execution status, error rates, frequency
System Log	Admin → System Log	Engine-level errors, auth failures
Audit Log	Admin → Reports → Activity	User events that triggered pipelines
Distributed Engine Log	Admin → Distributed Engine → Status	Engine connectivity, script execution

Ongoing Maintenance Checklist

Establish a regular cadence to review your pipelines. Recommended schedule:

🗓 Weekly

☑ Review Pipeline Runs for error trends
☑ Verify Run-As account hasn't been locked
☑ Check fire frequency for anomalies

📅 Monthly

☑ Audit all active policies and pipelines
☑ Review recipient/endpoint validity
☑ Test pipeline execution end-to-end
☑ Remove decommissioned pipelines

Alerting on Pipeline Failures

Create a meta-pipeline — a pipeline that monitors for failed pipeline runs using the System Log trigger — to alert your operations team when any pipeline encounters an error.

💡

SIEM Integration Secret Server's audit logs can be forwarded to your SIEM (Splunk, Microsoft Sentinel, QRadar) via Syslog. Create SIEM alerts on pipeline execution events for centralized monitoring and correlation with other security telemetry.

Performance Considerations

⚡ High-Volume Triggers

Triggers like Secret View on high-usage secrets can generate thousands of executions per day. Add targeted filters to reduce volume and prevent SMTP/webhook rate limiting.

🐌 Script Task Latency

PowerShell scripts executing via Distributed Engine add latency. For time-sensitive pipelines, prefer email/webhook tasks over script tasks when possible.

🔄 Recursive Loops

A pipeline that modifies a secret can trigger itself again. Use the Stop Conditions feature or target filters precisely to prevent infinite execution loops.

⬡ Module 10 · Assessment

Knowledge Check

Test your understanding of Delinea Secret Server Event Pipelines before going live.

❓ Question 1 of 5

When multiple filters are applied to a pipeline, what logic governs whether the pipeline executes?

OR logic — any filter matching is sufficient

AND logic — all filters must match

XOR logic — exactly one filter must match

NAND logic — filters are inverted

✓ Correct! Multiple pipeline filters use AND logic — every filter condition must be satisfied for the pipeline to proceed. This allows precise targeting but can over-restrict if configured incorrectly.

✗ Not quite. Filters use AND logic — all conditions must be true simultaneously for the pipeline to fire. This is why it's important to test filter stacks carefully.

❓ Question 2 of 5

What is the correct order of a pipeline's architectural components?

Action → Task → Filter → Trigger

Filter → Trigger → Action → Task

Trigger → Filter → Task → Action

Trigger → Task → Filter → Action

✓ Correct! The flow is: an event fires the Trigger → Filters determine if conditions match → Tasks execute the operations → resulting in the final Action/outcome.

✗ Incorrect. The correct order is Trigger → Filter → Task → Action. Triggers fire the pipeline, filters narrow scope, tasks perform operations, and actions are the outcomes.

❓ Question 3 of 5

A pipeline is configured and saved, but it's not executing when the trigger event occurs. What is the most likely cause?

The pipeline has no tasks defined

The policy containing the pipeline is in Inactive status

The pipeline name contains special characters

The Run-As account has too many permissions

✓ Correct! A pipeline will not execute unless it is assigned to an Active policy. The policy controls activation state — simply saving a pipeline is not enough to make it run.

✗ Not quite. The most common cause is the policy being in Inactive status. Pipelines only execute when assigned to an Active policy that covers the event's scope.

❓ Question 4 of 5

Which variable would you use in an email task to include the name of the user who triggered the pipeline event?

$SECRET_OWNER

$TRIGGERED_BY

$USER_DISPLAY_NAME

$EVENT_USER

✓ Correct! $USER_DISPLAY_NAME contains the display name of the user whose action triggered the pipeline event. Use $USER_USERNAME for the login name and $USER_EMAIL for their email.

✗ Incorrect. The correct variable is $USER_DISPLAY_NAME. This contains the display name of the user who triggered the event. Other valid user variables include $USER_USERNAME and $USER_EMAIL.

❓ Question 5 of 5

What is the safest way to immediately halt a production pipeline without deleting it?

Delete all tasks from the pipeline

Change the trigger to an event that never fires

Set the policy status to Inactive

Remove the Run-As account

✓ Correct! Setting the policy to Inactive is the cleanest, fastest rollback — it takes effect immediately, preserves the pipeline configuration, and can be re-activated instantly when needed.

✗ Not the best approach. The cleanest rollback is setting the Policy to Inactive status. This immediately stops execution, preserves all configuration, and is fully reversible.

Event Pipelinesin Delinea Secret Server

What Are Event Pipelines?

Core Concepts

Common Use Cases

Prerequisites & Access

Required Permissions

Pre-Flight Checklist

Enabling the Feature

Creating Your First Pipeline

Accessing Event Pipelines

Step-by-Step: New Pipeline

Naming Conventions (Best Practice)

Triggers & Filters

Trigger Event Reference

Understanding Pipeline Filters

Filter Stacking Logic

Tasks & Actions

Available Task Types

Configuring a Send Email Task

Pipeline Variable Reference

Configuring a Webhook Task

Pipeline Policies

Pipeline vs. Policy: The Distinction

Creating a Policy

Policy Inheritance Model

Testing & Validation

Testing Strategy

Test Checklist

Reading the Pipeline Run Log

Common Errors & Fixes

Publishing & Activation

Pre-Publication Checklist

Activation Steps

Version Control Best Practice

Monitoring & Logs

Key Monitoring Locations

Ongoing Maintenance Checklist

Alerting on Pipeline Failures

Performance Considerations

Knowledge Check

Event Pipelines
in Delinea Secret Server