Skip to main content
Documentation
Documentation
Administrator Guide
Last Updated: 2024-11-01
Setup Considerations: Requests

Setup Considerations: Requests

You can use this topic to help make decisions when planning your configuration and use of Requests. It explains:
  • Why to set it up.
  • How it fits into the rest of Workday.
  • Downstream impacts and cross-product interactions.
  • Security requirements and business process configurations.
  • Questions and limitations to consider before implementation.
Refer to detailed task instructions for full configuration details.

What It Is

High-level process:
  • Administrators can create multiple request types with different steps and approvers.
  • Users initiate requests and can initiate requests on behalf of someone else.
  • Reviewers can review requests initiated by users and, if needed, make changes to the request before the completion step.
  • Process users implement requests by approving, closing, and setting resolutions on closed requests.
The
Request
 business process enables you to set up custom request processes that users initiate and administrators track within Workday. You create different request processes by defining who makes, reviews, approves, and completes the requests. When the process completes, you have a record of this information.
A request doesn't change anything on its own. It's a request for action.

Business Benefits

You can:
  • Define your own request types and process flows.
  • Consolidate request processes across your organization, eliminating requests submitted through email, word-of-mouth, and so on.
  • Keep track of the initiation, review, approval, implementation, and final verification processes for your requests.
  • Audit the
    Request
     business process history for completed requests.
  • View the request on the audit trail for that business object if a request is associated with a Workday business object.
  • Configure the security access, steps, and levels of required approval.

Use Cases

You can consolidate your organization's processes for making requests and changes by configuring the
Request
 business processes. Employees can then apply for new resources or changes to existing resources, such as:
  • Business processes.
  • Job descriptions.
  • Learning courses.
  • Office equipment.
  • Organizations.
  • Reports.
  • Security groups.
  • System account access.
You can initiate requests on behalf of someone else, such as:
  • Submit a return to office request for an employee.
  • Request security access or roles for another person.
  • Submit a department request on behalf of a managing director, chief of staff, or department head.
  • Submit HR-related requests for an employee.

Questions to Consider

  • What are the request processes you want Workday to handle?
  • What are the request process details for your request processes, such as:
    • Who can make a request?
    • Who can approve a request?
    • Who will fulfill a request?
    • How do you want to track and audit requests?
    • Is there information that I want to collect?

Recommendations

To simplify your setup, consider:
  • Using a rule-based
    Request
     business process definition for each request type you use. In this way, you create independent process flows for different request types.
  • Configuring the
    Requests
     worklet on the Home dashboard to display relevant tasks and reports, improving usability and accessibility.
  • Configuring a request type to enable users to initiate requests on behalf of another person with a worker or a nonworker role, like a student or extended enterprise learner. If required, you can change the configuration even after a request associated with the request type initiates.
To prevent redundancy with questionnaires, Workday recommends that you configure whether the
Describe the Request
 field on request types displays to users. This action helps you control what users see on their request form when they run the
Request
 business process.

Requirements

  • The
    Review Request
    action step must always occur before the completion step in a
    Request
    business process.
  • The
    Close Request
     action step must always be the completion step in a
    Request
     business process.

Limitations

  • Only the request initiators and reviewers can change request content.
  • You can only link requests to the business objects Workday displays when you create a request type.

Tenant Setup

No impact.

Security

Configure the
Request
 business process and security policy in the System functional area.
The
Request
 business process defines the worker as the initiator of the
Request
 business process. When you configure the business process security policy, and you select the:
  • Hide Comments from Person
     check box, the worker won't be able to view comments on the
    Process
     tab of the
    Full Process Record
     that they didn't enter.
  • Hide Details from Person
     check box, the worker won't be able to view business process details.
When you select the check boxes, Workday displays comments or details of a Request event to nonworkers (such as an integration user or implementer) that have access to the event.
The
Hide Details from Person
 check box overrides the
Hide Comments from Person
 check box. Meaning, if you only select the
Hide Details from Person
 check box, Workday hides both comments and details of the event.
Understand segment-based security groups and segmented security, and determine how you want to restrict request type access for groups of workers.
When you configure security for a request type, security groups you select for the
View All
 field can view all event details for requests of this request type.
Configure these domains in the System functional area:
Domains
Considerations
Set Up: Requests
Users secured to this domain can create and view request types.
Self-Service: Requests
Users secured to this domain can view their requests and request types.
View: Requests
Users secured to this domain can view requests.
Set Up: Request Type Security Segments
Users secured to this domain can create request type security segments.
Reports: Requests
Users secured to this domain can view reporting on requests.

Business Processes

Business process administrators can add multiple steps to a
Request
 business process definition, including approvals or additional questionnaires. Workday routes request steps according to the organization of the request initiator. Example: Workday routes a step to the HR Partner of the initiator and not the subject of the request.
  • When you don't create a rule-based
    Request
     business process definition for a request type, Workday uses the default
    Request
     business process definition.
  • When you configure a rule-based
    Request
     business process definition, you can create a hierarchy of condition rules that determines which
    Request
    business definition Workday runs.

Reporting

Reports
Considerations
My Requests
Displays all requests initiated by the user.
All Requests
Displays all requests initiated in Workday.
My Recent Requests
Displays open and completed events initiated in the past 7 days by the user.
Requests in Progress
Displays all request business processes currently underway.
Requests Submitted on My Behalf
Displays all requests initiated by another person on behalf of the user. We display information such as the request:
  • Completion date and initiation date.
  • Status and resolution.
View Request Types
Displays the request types the user can access.
You can use these report data sources in your custom reports:
  • All Requests
  • My Requests
  • Request Types
  • Requests On My Behalf
The
Request Description Display
 setting won't impact your reports, and the
Describe the Request
 field will continue to display in your reports.

Integrations

No impact.

Connections and Touchpoints

No Impact.