What is The Request Framework?

Think of a process that you have at your organization that is outside of Workday. Does it require a list of questions and documentation? Does it need approvals? Do you need to report on completion status and what was requested in the process for future audit reports? If so, you might be able to use the Request Framework in Workday to assist.

The Request Framework is a Business Process that organizations can use to track processes that are not connected to a regular Workday Business Process. An example is tracking requests of changes to Business Processes. Someone might ask that you need to create a new step in the Hire Business Process for a Document Review. Currently, you would get that request either through an email or by someone messaging you to change the Business Process. If you need to have the change request approved, you will send that through another email, and then finally you need to complete the process. All of this is done outside of Workday with no clear direction. With the Request Framework, you can define security groups of who needs to approve change requests for Business Processes, who is going to implement the change, and who will verify and finalize the completion.

The Request Framework is unique as your organization can complete multiple request types that follow different business process rules. As a default, the Request Business Process requires the request type selected and the description of the request. From there, the Business Process just needs to have a close step of who is closing out the request.

The Request Framework is not automatically turned on in an organizations tenant. There is security that needs to be

configured and a default business process needs to be set up, however from there an organization can build out as many processes they would like in their Workday tenant. Documentation on basic security and setup from Workday can be found at this link: Workday Community documentation on Request Framework.

Request Types are defined by each organization differently. Each request type can have different initiating questions and different business processes. Each is unique and limited to what the organization would like to define.

Here are a few examples of from other organizations of their Request Types that they have built:

• Tuition Waiver

• IT Access

• Return to office exception request.

• Creating a new job profile

• Modifying a business process

• Furniture purchase requests

• Create a new supervisory organization.

• Request to attend an external training.

Each example above shows different use cases the organizations has built out. There are numerous different use cases that organization can create to improve workflows. As a reminder, make sure to build and test in your implementation tenants before moving into your Production tenant.

Pros

• Have a process in Workday to track the number of requests and have a clear approval path for requests.

• Keep track of requests and requirements inside of Workday.

• Keep initiators of the request informed of where the requests are at in the process through reports or notifications.

• Attach requests to certain specific Workday objects such as business process, workers, location, organization so an auditor can view why that object was ‘changed’ in Workday in the future.

• As of 2022R1, organizations can now create requests on behalf of a user. Previously, you had to have specific individuals complete their requests or set up questions to analyze who the requester was in Workday. Now you can create a new request type that is on behalf of a specific worker.

• Creating segment security groups to restrict reporting and who can view certain request types.

Cons

• Request business processes don’t allow you to specific other Workday tasks. Organizations must create to dos to get users to complete specific tasks in a request process.

• Don’t put complex request processes in Workday. More steps and multiple approvals can overcomplicate the process.

• Questionnaire data on a request needs to have multiple calculated fields for reporting on or sending out custom notifications.

Tips for successful Request Processes creation:

• Get your plan together outside of Workday. Your organization needs to figure out who the initiator is for the request type. Will there need to be restrictions based on organizations or other roles?

• Review all the questions you need to ask the initiator to begin the task? What does the approvers or closers need to know? This will help with defining questions at the beginning of the request.

• Define the approval and closure steps: Who is approving and who will close out the request. Are there any tasks that needs to be done in Workday? Do the next steps need to include further questions to ask certain security groups?

• Create a test in an implementation tenant and view this data with your project team to verify it is working as plan.

  • Create your Request Type and define the Workday object this could sit on in Workday. If no Workday object exists in the list, leave blank.

  • Create a questionnaire if needed for your Request Type.

  • Set the security for the Request Type on the main Request Business Process. A suggestion is to create Segment Security groups so groups can only see Requests based on those Request Types and not all Request Types.

• Once you get test results and it is working correctly, use the Request Standard reports to see how data is flowing. This will show the basic information of the Request. Further details such as questions on the questionnaires will need to have a Custom Report created from the Request Workday object.