Workday Event Collector
This Integration is part of the Workday Pack.#
Supported versions
Available on Cortex XSIAM.
Use Workday Event Collector integration to get activity loggings from Workday. This integration was integrated and tested with API v1.
Configure Workday Event Collector in Cortex#
| Parameter | Description | Required |
|---|---|---|
| Server URL (e.g. https://WORKDAY-HOST/ccx/api/privacy/v1/TENANT_NAME) | The Workday privacy REST API endpoint, including the tenant name: https://<host>/ccx/api/privacy/v1/<tenant>. Take the host and tenant from the Workday REST API Endpoint in the View API Clients report (https://<host>/ccx/api/v1/<tenant>) and replace /api/v1/ with /api/privacy/v1/. | True |
| Token endpoint (e.g. https://WORKDAY-HOST/ccx/oauth2/TENANT_NAME/token) | The Token Endpoint shown in the View API Clients report: https://<host>/ccx/oauth2/<tenant>/token. | True |
| Client ID | The Client ID of the API client registered with the Register API Client for Integrations task. This collector does not use a username. | True |
| Client Secret | The Client Secret of the registered API client. | True |
| Refresh Token | Non-expiry Workday API refresh token, generated with Manage Refresh Token for Integrations for the registered API client. | True |
| Trust any certificate (not secure) | False | |
| Use system proxy settings | False | |
| First fetch timestamp (<number> <time unit>, e.g., 12 hours, 7 days) | False | |
| Max events per fetch | The maximum number of audit logs to retrieve for each event type. For more information about event types see the help section. | False |
Commands#
You can execute these commands from the CLI, as part of an automation, or in a playbook. After you successfully execute a command, a DBot message appears in the War Room with the command details.
workday-get-activity-logging#
Returns activity loggings extracted from Workday.
Base Command#
workday-get-activity-logging
Input#
| Argument Name | Description | Required |
|---|---|---|
| limit | The maximum number of loggings to return.. Default is 1000. | Optional |
| offset | The zero-based index of the first object in a response collection. Default is 0. | Optional |
| from_date | The date and time of the earliest log entry. The default timezone is UTC/GMT. The time format is "{yyyy}-{mm}-{dd}T{hh}:{mm}:{ss}Z". Example: "2021-05-18T13:45:14Z" indicates May 18, 2021, 1:45PM UTC. Possible values are: . | Required |
| to_date | The time format is "{yyyy}-{mm}-{dd}T{hh}:{mm}:{ss}Z". Example: "2021-05-18T13:45:14Z" indicates May 18, 2021, 1:45PM UTC. Possible values are: . | Required |
| should_push_events | Set this argument to True in order to create events, otherwise the command will only display them. Possible values are: True, False. Default is False. |
Context Output#
There is no context output for this command.
Command example#
!workday-get-activity-logging limit=4 from_date=2023-04-24T07:00:00Z to_date=2023-04-24T08:00:00Z
Human Readable Output#
Activity Logging List#
| Activity Action | Device Type | Ip Address | Request Time | Session Id | System Account | Target | Task Display Name | Task Id | User Activity Entry Count | User Agent |
|---|---|---|---|---|---|---|---|---|---|---|
| test_action | test_device | 1.1.1.1 | 2023-04-24T07:00:00Z | test_session_id | 123 | id: 1234 descriptor: test_descriptor href: test_href | test_display | 1 | 1234 | test_agent |
| test_action | test_device | 1.1.1.1 | 2023-04-24T07:00:00Z | test_session_id | 123 | id: 1234 descriptor: test_descriptor href: test_href | test_display | 2 | 1234 | test_agent |
| test_action | test_device | 1.1.1.1 | 2023-04-24T07:00:00Z | test_session_id | 123 | id: 1234 descriptor: test_descriptor href: test_href | test_display | 3 | 1234 | test_agent |
| test_action | test_device | 1.1.1.1 | 2023-04-24T07:00:00Z | test_session_id | 123 | id: 1234 descriptor: test_descriptor href: test_href | test_display | 4 | 1234 | test_agent |
Known Limitations#
By design, each fetch only requests events up to now - 60 seconds, so the collector always lags 60 seconds behind the current time. This lag is required because Workday publishes a minute's events gradually and not strictly in timestamp order. Waiting ensures each time window is fully published before it is fetched, which prevents events from being missed. As a result, the most recent ~60 seconds of events are collected on the next fetch cycle rather than the current one.