Many organizations need reports only when requested instead of running them on a fixed schedule. A common example is an administrator requesting an access report for auditing purposes.
Instead of permanently scheduling the report, we can:
- Create a temporary scheduled search
- Execute the report immediately
- Wait for report generation
- Delete the temporary schedule
This keeps the tenant clean while still allowing users to receive reports whenever needed.
In this article, we’ll build this solution using SailPoint Identity Security Cloud (ISC) Workflows and explain every API involved.
Solution Flow
Interactive Workflow
│
▼
Get Identity
│
▼
Create Scheduled Search
│
▼
Execute Saved Search
│
▼
Wait 2 Minutes
│
▼
Delete Scheduled Search
│
▼
End
Prerequisites
Before starting, make sure you have:
- A Saved Search already created
- OAuth Client with required API scopes
- Workflow HTTP Request action
- Workflow trigger (Interactive Process)
Step 1 – Get the User Identity
The workflow begins by identifying who launched it.
Workflow Action
Get Identity
Input
{
“id”: “$.trigger.launchedBy.id”
}
The value
$.trigger.launchedBy.id
comes from the workflow trigger and represents the identity that clicked Run Workflow.
Example response
{
"id": "2c918084123456789",
"name": "John Doe",
"email": "john.doe@company.com"
}
Why do we need this?
Later, while creating the scheduled search, we’ll dynamically assign this user as the email recipient.
Step 2 – Create a Temporary Scheduled Search
Now we’ll call the Scheduled Search API.
API
POST /v2026/scheduled-searches
Purpose
Creates a temporary schedule for an existing Saved Search.
HTTP Request
POST /v2026/scheduled-searches
Request Body
{
"displayQueryDetails": false,
"emailEmptyResults": true,
"enabled": true,
"recipients": [
{
"id": "{{$.getIdentity.id}}",
"type": "IDENTITY"
}
],
"savedSearchId": "00c7dcdf-0d7c-42b1-94b2-8171f5466b4e",
"schedule": {
"type": "DAILY",
"timeZoneId": "America/Chicago",
"hours": {
"type": "LIST",
"values": [
"1"
]
}
}
}
Notice this line:
"id": "{{$.getIdentity.id}}"
Instead of hardcoding the recipient, we’re using the output from the Get Identity step.
This allows the workflow to send the report to whoever launches it.
Important Request Fields
savedSearchId
Specifies which Saved Search should run.
Example
"savedSearchId":"00c7dcdf..."
recipients
Defines who receives the report.
"recipients":[
{
"id":"{{$.getIdentity.id}}",
"type":"IDENTITY"
}
]
emailEmptyResults
true
Even if the report returns no data, an email is still sent.
displayQueryDetails
false
Prevents exposing the search query inside the email.
schedule
Although we’re running this report immediately, the API requires a schedule object.
The schedule simply acts as a placeholder because we’ll execute it manually in the next step.
API Response
Example
{
"id":"e43d7652-1234-abcd",
"savedSearchId":"00c7dcdf...",
"enabled":true
}
The important value is
"id"
This is the Schedule ID.
We’ll use it twice later.
Step 3 – Execute the Saved Search Immediately
Creating a schedule does not execute the report.
We must explicitly call another API.
API
POST /v2026/saved-searches/{savedSearchId}/execute
Request
{
"scheduleId":"{{$.hTTPRequest.body.id}}"
}
Notice
{{$.hTTPRequest.body.id}}
This value comes from the previous API response.
The workflow dynamically passes the Schedule ID to the Execute API.
What happens internally?
Create Schedule
│
returns
│
Schedule ID
│
passed into
▼
Execute Saved Search
Without the Schedule ID, the execute API cannot identify which temporary schedule should be run.
Step 4 – Wait for Report Generation
The report generation is asynchronous.
Instead of deleting the schedule immediately, we wait.
Workflow Action
Wait
Configuration
2 Minutes
Why?
This gives SailPoint enough time to:
- Execute the search
- Generate the report
- Email the report to the recipient
Deleting the schedule too early could prevent execution.
Step 5 – Delete the Temporary Schedule
Once the report has been generated, we clean up.
API
DELETE /v2026/scheduled-searches/{scheduleId}
Example
DELETE /v2026/scheduled-searches/e43d7652-1234-abcd
Workflow Expression
{{$.hTTPRequest.body.id}}
This is the same Schedule ID returned when the schedule was created.
After deletion:
- No unused schedules remain
- The tenant stays clean
- Future executions create a fresh schedule
Complete API Sequence
| Step | API | Purpose |
|---|---|---|
| 1 | Get Identity | Retrieve the user launching the workflow |
| 2 | POST /scheduled-searches |
Create a temporary schedule |
| 3 | POST /saved-searches/{id}/execute |
Execute the saved search immediately |
| 4 | Wait | Allow report generation |
| 5 | DELETE /scheduled-searches/{id} |
Remove the temporary schedule |
Data Flow Between Steps
Workflow Started
│
▼
Get Identity
│
▼
Identity ID
│
▼
Create Scheduled Search
│
▼
Schedule ID
│
├─────────────► Execute Saved Search
│
└─────────────► Delete Scheduled Search
Benefits of This Approach
- No permanent scheduled reports are created.
- Reports can be generated on demand whenever required.
- The workflow dynamically sends the report to the user who initiated it.
- Temporary schedules are automatically cleaned up after execution, reducing administrative overhead.
- The solution is reusable for any Saved Search by changing only the
savedSearchId.
Conclusion
Using SailPoint ISC Workflows together with the Scheduled Search APIs makes it easy to generate reports on demand without leaving unnecessary schedules in your tenant. This pattern creates a temporary schedule, executes the report immediately, waits for processing to complete, and then removes the schedule automatically. It provides a clean, scalable approach for self-service reporting while keeping the environment organized and easy to maintain.
schedulinganddeletingonrequestbasis20260628.json (4.4 KB)