Skip to main content
Sumo Logic

Collect Logs for the Workday App

This page explains how to collect logs from Workday and ingest them into Sumo Logic for use with the Workday App predefined dashboards and searches.

This page explains how to collect logs from Workday and ingest them into Sumo Logic for use with the Workday App predefined dashboards and searches. Click a link to jump to a section:

Collection Overview

Sumo Logic collects logs from Workday via a script that calls the Workday APIs. As part of the script configuration, you need to first configure log types that need to be collected, and these logs are then forwarded to Sumo Logic’s HTTPS source.

Before You Deploy

Sumo Logic collects data from the User Activity and Signon Activity Reports via the Workday APIs. Once data collection is set up, the data in the Sumo Logic platform is analyzed via the Workday app in the Sumo Logic app catalog. 

User activity data is collected through the Workday Audit Logs API. To ensure that no sensitive information is being sent to Sumo Logic via this report, please run the “User Activity” Report and check the columns (specifically the Target column). If the data does have any sensitive info, you can enable data masking for the security group created in the steps outlined below by following the instructions in this doc.

Recommended Deployment Process

We recommend you to deploy the Sumo Logic - Workday integration using the following guidelines.

  1. Start by configuring the collector source as described in the sections below for your Workday Sandbox environment. 
  2. Once the integration has been successfully deployed and tested in your Workday Sandbox environment, only then should you move to configuring this integration in your Workday production environment.  

Configuring collection for Workday includes the following tasks:

Step 1: Configure the Workday Portal

This section demonstrates how to configure the Workday portal to integrate with Sumo Logic’s collection scripts.
Configuring the Workday portal involves the following steps:

Step 1.1: Create an Integration System User

Step 1.2: Create a Security Group

Step 1.3: Register the API Client

Step 1.4: Enable your tenant to send data

Step 1.5: Create a Custom sign on report

Step 1.1: Create an Integration System User
  1. Access the Create Integration System User task and provide the following parameters:
    • User Name. SumoLogic_ISU
    • New Password and New Password Verify. Enter the password 
    • Do Not Allow UI Sessions. Check the box
    • Session Timeout Minutes. 0 (Disable session expiration)

  2. Click OK.
  3. Exempt the created user from the password expiration rule.
    • Access Maintain Password Rules task.
    • Add the users to System Users exempt from password expiration.

Step 1.2: Create a Security Group
  1. To create a security group, access the Create Security Group task and provide the following parameters:
    • Type of Tenanted Security Group. Integration System Security Group (Unconstrained)
    • Name. SumoLogic Client Security Group 


  1. Click OK.
  2. In the Edit Integration System Security Group (Unconstrained) window provide the following parameters:
    • Integration System Users. SumoLogic_ISU
    • Comment (Optional). Provide a short description

  3. Click OK.
  4. To attach the security group to a domain, access the View Domain task for the domain System Auditing.
  5. Select Domain > Edit Security Policy Permissions from the System Auditing related Actions menu.

  6. Add the SumoLogic Client Security Group you created to both the tables as below:
    • Report/Task Permissions table. View access
    • Integration Permissions table. Get access

  7. Click OK.
  8. To apply policy changes, access the Activate Pending Security Policy Changes task and activate the changes you made.

  9. Click OK.
Step 1.3: Register the API Client
  1. To register the API client, access the Register API Client for Integrations task, and provide the following parameters:
    • Client Name. Sumo Logic Workday Collector
    • Non-Expiring Refresh Tokens. Yes
    • Scope. System

  2. Click OK.
  3. Copy the Client Secret and Client ID before you navigate away from the page and store it securely.
  4. Click Done.
  5. To generate a refresh token, access the View API Clients task and copy the below two parameters from the top of the page:
    • Workday REST API Endpoint. The endpoint to use access to the resources in your Tenant.
    • Token Endpoint. The endpoint used to exchange an authorization code for a token (if you configure authorization code grant).

  6. Go to API Clients for Integrations tab hover on “Sumo Logic Workday Collector API” client and click on the three-dot action buttons.
  7. In the new pop up window, click API Client > Manage Refresh Token for Integrations

  8. In the Manage Refresh Token for Integrations window, select “SumoLogic_ISU” in the Workday Account field and click OK.

  9. In the newly opened window, select Generate New Refresh Token checkbox and click OK.

  10. Copy the value of the Refresh Token column from the opened window and click Done.

Step 1.4: Enable your tenant to send data
  1. To enable your Tenant to send data, access the Edit Tenant Setup - System task and ensure that the Enable User Activity Logging checkbox is selected.

  2. Access the Edit Tenant Setup - Security task and ensure that the OAuth 2.0 Clients Enabled checkbox is selected.

Step 1.5: Create a Custom sign on report

Note -  For customers that do not make use of the Recruiting Functional Area. the standard Candidate Signon report may not be available. Alternative is to create a new custom report with Data Source = “All System Account Signons” and Data Source Filter = “Workday System Account Signons in Range”. You can configure the fields using Excel.

  1. Go to Copy  Standard Report to Custom Report task to create a Customs SignOn Report.
  2. Select “Candidate Signons and Attempted Signons” in Standard Report Name dropdown and click OK.

  3. In the new window, select Optimized for Performance checkbox, edit the report Name to Custom Signons and Attempted Signons Report and click OK.

  4. In the next window, edit the Data Source Filter field and select Workday System Account Signons in Range filter.
  5. Go to the Columns tab and click the + button to add the following new fields:
    • Operating System
    • Password Changed
    • Request Originator
    • SAML Identity Provider 
    • Forgotten Password Reset Request
    • Multi-Factor Type
    • Is Device Managed
    • UI Client Type
    • Browser Type
    • Device is Trusted

  6. Remove the text in the Column Heading Override column, for Field > Session ID and Field > System Account.

    After configuring all the fields you can verify all the fields using the Excel.
  7. Go to the Advanced tab and click the Enable As Web Service checkbox under Web Service Options.

  8. Go to the Share tab, enable Share with specific users and groups option, add SumoLogic_ISU in the Authorized Users field, and click OK.

  9. Click Done. You can also test it by clicking the Run button.

  10. To get the Report URL, search for Custom Signons and Attempted Signons Report in the search bar and run the report.
  11. Click the Actions button and go to Web Service > View URLs.

  12. Click OK and copy the URL from JSON link. You will need this later while configuring the collection.


Step 2: Add a Hosted Collector and HTTP Source

Note -  This step is not needed if you are choosing to configure the Cloud To Cloud Collector Source.

In this step, you create a hosted collector and HTTP source to receive data from the scripts that collect data from your Workday tenant.

  1. Configure a Hosted Collector, or select an existing hosted collector for the HTTP source.

  2. Configure an HTTP source on the hosted collector

Make a note of the HTTP address for the source. You will need it when you configure the collection for the Workday scripts in the next step.

In this section, we will configure a collection of login and audit logs  from Workday and send them to Sumo Logic via one of the methods listed below. 

  • For non-FedRamp Sumo Logic deployments

  • If you are using the Sumo Logic FedRamp deployment, you can either use a Sumo Logic Workday collection script to be run in an Amazon Web Services (AWS) environment using the AWS Lambda service, or run Sumo Logic Python scripts to run periodically on a Linux machine via a cron job.

Deploy the Sumo Logic Workday SAM Application in your AWS environment

In this step, you deploy the SAM application, which creates the necessary resources in your AWS account.

To deploy the Sumo Logic Workday SAM Application, do the following:

  1. Go to
  2. Search for sumologic-workday, and select the Show apps that create custom IAM roles or resource policies checkbox and click the app link when it appears.

  3. When the Sumo Logic app page appears, click Deploy.


  4. In the AWS Lambda > Functions > Application Settings panel, specify the following parameters in the corresponding text fields:

    • HTTPLogsEndpoint. Paste the URL for the HTTP Logs source from Step 2.

    • SignonReportUrl. Paste the signon report url from Step 1.5.

    • IntegrationSystemUserPassword: Paste the SumoLogic_ISU account password copied from Step 1.1.

    • IntegrationSystemUsername. Name of the account created in Step 1.1.

    • WorkdayRestApiEndpoint.  Paste the Workday Rest API endpoint copied from Step 1.4.

    • RefreshTokenEndpoint.  Paste the Token endpoint copied from Step 1.4.

    • ClientId. Paste the API Client ID copied from Step 1.4.

    • ClientSecret.  Paste the API Client SECRET copied from Step 1.4.

    • RefreshToken. Paste the Refresh token generated from Step 1.4.


  5. Click Deploy.

  6. After the deployment, you can verify whether all the resources are created completely.


This section shows you how to configure script-based log collection for the Sumo Logic Workday App.


This task makes the following assumptions:

  • You have successfully added a Hosted Collector and HTTP source and copied configuration parameters (HTTPLogsEndpoint, SignonReportUrl, IntegrationSystemUserPassword, IntegrationSystemUsername,  WorkdayRestApiEndpoint,  RefreshTokenEndpoint, ClientId, ClientSecret, and RefreshToken) from the Workday console, as described in Add a Hosted Collector and HTTP Source section.

  • You are logged in to a Linux machine as the user account with which you will install the collector. If not, use the following command to switch to that account: sudo su <user_name>

This task shows you how to install the script on a Linux machine.

To deploy the script on a Linux machine, do the following:

  1. If pip is not already installed, follow the instructions in the pip documentation to download and install pip.
  2. Log in to a Linux machine (compatible with either Python 3.7 or Python 2.7).
  3. Do one of the following:
    • For Python 2, run the following command: pip install sumologic-workday

    •  For Python 3, run the following command: pip3 install sumologic-workday

  4. Create a sumoworkdaycollector.yaml configuration file in the home directory and fill in the parameters as shown in the following example.

  HTTP_LOGS_ENDPOINT: <Paste the URL for the HTTP Logs source from step 2.>

  ISU_PASSWORD: <PASSWORD copied from Step 1.a>
  TIMEOUT: 600

  AUDIT_API_URL: "/auditLogs"
  WORKDAY_REST_API_ENDPOINT: <Workday Rest API endpoint copied from Step 1.g>
  REFRESH_TOKEN_ENDPOINT: <Token endpoint copied from Step 1.g>
  CLIENT_ID: <API Client ID copied from 1.f>
  CLIENT_SECRET: <API Client SECRET copied from 1.f>
  REFRESH_TOKEN: <Refresh token generated from Step 1.g>
    - "Search in Main Page (Web Service)"
    - "Home"

5. Create a cron job to run the collector every 5 minutes, (use the crontab -e option). Do one of the following:

  • For Python 2, add the following line to your crontab:
    */5 * * * *  /usr/bin/python -m sumoworkdaycollector.main > /dev/null 2>&1

  • For Python 3, add the following line to your crontab:
    */5 * * * *  /usr/bin/python3 -m sumoworkdaycollector.main > /dev/null 2>&1

This section provides a list of variables for Workday that you can define in the configuration file.

The Workday specific configuration is shown in below two sections:

  • Workday_Report_Config - Remove this section to stop collecting SignOn logs from the custom report.
  • Workday_API_Config section - Remove this section to stop collecting audit logs via REST API.

You can view the entire configuration with default settings here. For SAM deployments you can update   sumoworkdaycollector.yaml file in the AWS Lambda console editor.

Advanced Configuration_SS_1.png

The following table provides a list of variables for Workday that you can optionally define in the configuration file.

Variable Usage Default
API_CALL_DELAY_SECONDS This is the sleep time between multiple API calls to the Workday. The default value is 60 seconds.
TIMEOUT in Workday_Report_Config section This is the maximum time the request waits for the Workday RAAS API before it times out when making a call. The default value is 600 seconds.
MAX_FETCH_INTERVAL And MIN_FETCH_INTERVAL In Workday_Report_Config secction The Workday RAAS API fetches data between a start and end interval. Depending on the users in your tenant the data may exceed 2 GB. The maximum and minimum interval between start and end time is controlled by these two settings. Calibrate these two settings such that MIN_FETCH_INTERVAL contains less than 2GB data always. Set the MAX_FETCH_INTERVAL in such a way that it does not put too much load on your tenant. MAX_FETCH_INTERVAL: The default is 3600 that is 1 hour.
MIN_FETCH_INTERVAL: The default is 60 that is 1 minute.
PAGINATION_LIMIT in Workday_API_Config section The number of events fetched in a single page. The default value is 100 rows.
TIMEOUT in Workday_API_Config section This is the maximum time the request from a script waits for the REST API before it times out. The default value is 60 seconds.
BACKFILL_DAYS in Collection Section The number of days before the event collection will start. If the value is 1, then events are fetched from the last 24 hours. The maximum allowed value is 1. The default value is 0.
ENABLE_LOGFILE in Logging Section Set to TRUE to write all logs and errors to a log file. The default value is False.
ENABLE_CONSOLE_LOG  in Logging Section It enables printing logs in a console. The default value is True.
LOG_FILEPATH in Logging Section The path of the log file used when ENABLE_LOGFILE is set to TRUE. Default is /tmp/sumoworkdaycollector.log
NUM_WORKERS in Collection Section The number of threads to spawn for API calls. The default is 2 concurrent requests.
MAX_RETRYin Collection Section The number of retries to attempt in case of request failure. The default is 3 attempts. 
BACKOFF_FACTOR in Collection Section A backoff factor has to be applied between attempts after the second try (most errors are resolved immediately by a second try without a delay). If the backoff_factor is 0.1, then sleep() will sleep for [0.0s, 0.2s, 0.4s, …] between retries. The default is 5.
TIMEOUT in Collection Section Max Timeout while sending logs to Sumo Logic. The default is 60 seconds.
HTTP_LOGS_ENDPOINT in SumoLogic section HTTP source endpoint URL created in Sumo Logic for ingesting Logs.  
BLACKLIST_TASK_NAMES To filter out tasks that should not be ingested into Sumo Logic.

The default tasks are:

  • Search in Main Page (Web Service)
  • Home


This section shows you how to run the function manually and then verify that log messages are being sent from Workday.

To run the function manually, do the following:

  1. Enter  one of the following commands:
    • For python, use this command: python -m sumoworkdaycollector.main
    • For python3, use this command: python3 -m sumoworkdaycollector.main
  2. Check the automatically generated logs in  /tmp/sumoapiclient.log to verify whether the function is getting triggered.

  3. If you installed the collector as root user and then run it as a normal user, you will see an error message similar to the following because the config is not present in the home directory of the user running the collector. Switch to the root user and run the script again.

Traceback (most recent call last):
 File "/usr/local/lib/python2.7/dist-packages/sumoworkdaycollector/", line 190, in main
   ns = WorkdayCollector()
 File "/usr/local/lib/python2.7/dist-packages/sumoworkdaycollector/", line 29, in __init__
   self.config = Config().get_config(self.CONFIG_FILENAME, self.root_dir, cfgpath)
 File "/usr/local/lib/python2.7/dist-packages/sumoworkdaycollector/common/", line 22, in get_config
 File "/usr/local/lib/python2.7/dist-packages/sumoworkdaycollector/common/", line 34, in validate_config
   raise Exception("Invalid config")
Exception: Invalid config

Workday App logs are all in JSON format. The Workday App uses two types of logs and this section provides examples of the log types.

SignOn Logs

Sample message

"Signon":"wd-environments / Workday Production Automation: 2020 02 16 00 07 52 329 -0800",
"Workday_Account":"wd-environments / Workday Production Automation",
"Authentication_Type_for_Signon":"User Name Password",
“tenant_name:: “SumoLogic”

Audit Logs

Sample message

"taskDisplayName":"Workday System Status",
“tenant_name:: “SumoLogic”

Query Sample

The query sample provided in this section is from the Failed Login Reasons panel of the Workday - Login Activity dashboard.


  • Failed_Signon:*
  • Authentication_Failure_Message:*

Query String

_sourceCategory=workday_logs and _sourceName=signonlogs
| json auto
| where Failed_Signon=1
| count by Authentication_Failure_Message
| if (isBlank(Authentication_Failure_Message), "Unknown", Authentication_Failure_Message) as Authentication_Failure_Message
| sort by _count