Request Intake & Categorization

Summary

This article explains how to complete the BPM–HCM Project or Change Request form in TeamDynamix, including which fields are completed by the BPM-HCM team versus the requestor. It documents required fields, conditional submitter questions, and internal data standards that support automation and reporting. Accurate completion is required to ensure reliable workflows, reporting, and governance.

Body

The Request Intake & Categorization phase is the first step in the BPM-HCM project lifecycle. Every request for a business process change, optimization, or new configuration begins with the submission of the BPM – HCM Project or Change Request form in TeamDynamix (TDX).

The BPM-HCM team is actively partnering with the IT TeamDynamix (TDX) team to automate as much of the ticket update and lifecycle management process as possible. As automation functionality is developed, tested, and approved, enhancements will be implemented incrementally in the production environment. This phased approach supports greater consistency in ticket data, reduces manual effort, and improves the accuracy and reliability of reporting over time.

This form captures both submitter-provided information and internal BPM-HCM assessment data to ensure requests are properly routed, evaluated, prioritized, and tracked throughout the BPM project and change request lifecycle.

Jump to Section
Purpose Form Structure Governance Requirements
Internal BPM-HCM Fields Submitter Fields Key Notes
Back to Top    

Purpose

The purpose of this article is to outline:

  • How to complete the BPM-HCM Request Intake Form
  • Which fields are completed by the BPM-HCM team versus the requestor
  • How each field is used during intake, prioritization, automation, and reporting

Accurate and complete form entry ensures efficient triage, consistent prioritization, automation readiness, and transparency across BPM-HCM change management and project tracking processes.

Back to Top

Form Structure

The Request Intake Form is divided into two sections:

Internal BPM-HCM Fields
Completed exclusively by the BPM-HCM team during intake, review, prioritization, and project execution.
Submitter Fields
Completed by the individual requesting the Workday change, optimization, or information.
Important: Any field labeled “Internal” is not expected to be completed by the requestor and may not be visible in all submission views.

Back to Top

Field Completion & Governance Requirement

With the exception of the following two fields:

  • Internal: Functional Area Approver’s Name
  • Internal: Executive Approver’s Name

All other fields in the BPM-HCM Request Intake Form are required.

These fields are required because they:

  • Support TDX automation and workflow logic
  • Feed institutional reporting and performance metrics
  • Enable accurate prioritization, lifecycle tracking, and audit readiness

Failure to complete required fields accurately and consistently may:

  • Prevent automation from functioning as designed
  • Result in incomplete or inaccurate reporting
  • Impact project visibility, prioritization, and downstream decision-making
  • Be considered during individual and team performance evaluations where ticket management, documentation quality, and data accuracy are assessed

Back to Top

Internal Fields

Listed in the order they appear in the TDX form.

Field Who Completes Type Description
Internal: Percentage Complete BPM-HCM Dropdown Required. Tracks milestone progress (e.g., 0% Intake, 25% Discovery, 60% UAT).
Internal: HCM Prioritization Stage BPM-HCM Dropdown Required. Intake status (Proposed, Discovery, Post-Discovery Review, Director Review).
Internal: Project Short Description BPM-HCM Text Area Required. A brief summary of the project or change request. This description will be displayed on executive dashboards and should clearly communicate the purpose and scope of the work in 1–3 concise sentences.
Internal: Payroll Impact BPM-HCM Dropdown Required. Internal validation of payroll impact.
Internal: Functional Area BPM-HCM Lookup Required. Primary HCM domain impacted.
Internal: Functional Area Approver’s Name BPM-HCM Lookup Required. Primary decision-maker for the affected functional area, typically at the director level.
Internal: Executive Approver’s Name BPM-HCM Lookup Required. Senior leader responsible for oversight of the affected functional area, typically a Senior Director, AVC, or equivalent. 
Internal: Business Process BPM-HCM Lookup Required. Workday business process impacted.
Internal: Business Capability BPM-HCM Lookup Required. BPM capability association (Project, Change, Service, Information)
Internal: Project Start Date BPM-HCM Date Actual start date.
Internal: Estimated Project Due Date BPM-HCM Date Estimated completion date.
Internal: Project Completion Date (Jira Close Date) BPM-HCM Date Populated when related Jira/WSS work is closed.
Internal: Most Recent Update of Project Request BPM-HCM Text Required. Must begin with the date in M.D.YYYY format, followed by a brief update (example: 1.1.2026 – Discovery session completed; summary sent).
Internal: Outcome Impact BPM-HCM Dropdown Primary outcome category (Compliance, Data Accuracy, Efficiency). Field is required once ticket is closed.
Internal: Outcome Narrative BPM-HCM Text Area Narrative describing expected or realized outcome. Field is required once ticket is closed. 
Internal: Responsible BPM-HCM Lookup Assigned BPM-HCM owner or group. Must be assigned to an individual once project or change begins. 
Internal: Type BPM-HCM Dropdown Internal classification used for reporting and prioritization.
Internal: Prioritization Recommendation BPM-HCM Text Provide a recommendation for how this project or change should be prioritized by leadership based on its effort, impact, and business need.
Internal: Business Impact Estimate BPM-HCM Dropdown Institutional or operational impact assessment based on effort/impact matrix score.
Internal: Business Impact Narrative BPM-HCM Text Describe the expected impact of this project or change on the business, including any benefits, risks, operational improvements, or affected stakeholders.
Internal: Effort Estimate BPM-HCM Dropdown Level of effort based on effort/impact matrix score (Light, Moderate, Heavy).
Internal: Effort Narrative BPM-HCM Text Describe the estimated effort required to complete this project or change, including the complexity, resources, and level of work involved.
Internal: Prioritization Decision Point for Leadership BPM-HCM Text Institutional or operational impact assessment based on effort/impact matrix score.

Back to Top

Submitter Fields

Standard Submitter Fields (Always Displayed)

Field Type Description
Title Text Clear, descriptive request title.
Requestor Lookup Requestor’s TDX user profile.
Acct/Dept Lookup Requestor’s home department or unit.
Primary Contact Lookup Main contact for follow-up and communication.
Core Functional Area(s) Multi-select Identifies impacted areas (HCM, Finance, Cross-Functional).
What process or activity is this request related to?  Text Name of process this request relates to (Hire Employee, Change Job, Recruiting)
Describe the process improvement or change you are requesting. Text Description of the improvement, redesign, or new process they would like to implement. Must include any challenges with current process if applicable.
What describes the reason for this request? Dropdown Reason for requesting a process innovation (improve efficiency, redesign or improve existing process)
Who would be impacted by this change? Dropdown Population impacted by requested process innovation (single department, HR team only, finance team only)
How urgent is this request? Single-select Urgency of process innovation request.
Attach any supporting documents or screenshots Attachment Optional supporting documentation.

Conditional Submitter Fields

The form dynamically displays additional questions based on the selection for “What type of optimization are you requesting?”

If Change (including Removal) Business Process is selected
Field Type Description
Name of existing Workday BP you want to change Text Exact name of the existing Workday business process.
What specific change(s) are you requesting to the existing process? Text Describe requested changes (routing, conditions, steps).
Why is this change needed? Text Business justification.
Does this project involve a software integration with Workday? Yes/No Indicates external system involvement.
What software is needed to be integrated with Workday? Text Conditionally displayed if Yes is selected.
What will this change or new process impact? Dropdown Compliance, efficiency, reporting, payroll, audit, policy, etc.
If New Business Process is selected
Field Type Description
What is the current name of the process you are proposing to build into Workday? Text Name of existing manual or external process.
What should this new process do in Workday? Text Desired functionality and outcome.
Why is the process needed? Text Business justification.
Does this project involve a software integration with Workday? Yes/No Indicates integration need.
What software is needed to be integrated with Workday? Text Conditionally displayed if Yes is selected.
What will this change or new process impact? Dropdown Compliance, efficiency, reporting, payroll, audit, policy, etc.

Back to Top

Key Notes

  • All fields are required unless explicitly noted as optional.
  • Submitters must complete all fields that populate based on their selections.
  • Internal fields are maintained exclusively by the BPM-HCM team.
  • Complete and accurate ticket data is essential for automation, reporting, governance, and accountability.

Parent and Child Tickets in TeamDynamix (TDX)

Parent and child tickets are used to organize related work under a single initiative while allowing individual tasks, phases, or work streams to be tracked independently.

  • Parent tickets represent the overarching project or primary request and are used for high-level tracking, reporting, and governance.
  • Child tickets represent discrete units of work (such as discovery activities, configuration changes, testing, or follow-up actions) that support the parent ticket.

To support this structure, the BPM – HCM Project or Change Request form has been updated to use the Major Incident service type so it can function as a parent ticket. A copy of this form has been created as BPM – HCM: Child Incident Change Request and configured as an Incident service type so it can be selected and linked as a child ticket.

The BPM-HCM team determines when a parent/child structure is appropriate based on scope, complexity, reporting needs, and workload distribution.

Creating a Parent Ticket from an Existing Ticket

  1. Open the ticket that will be associated with a parent.
  2. Select ActionsCreate Parent.
  3. When prompted to select a Major Incident form, choose BPM – HCM Project or Change Request.
  4. Click Save.
    • The required fields on the parent ticket can be completed after creation.
    • All required fields must be completed before the parent ticket can move out of the Intake phase.
  5. Click View Major Incident Case Created.

Once created, the Children tab on the parent ticket will show a count of 1, reflecting the original ticket that was converted into a child ticket.

Adding Additional Child Tickets to a Parent

Additional child tickets can be added to the parent ticket in one of two ways:

  • From the Children tab on the parent ticket, click Add New and complete the BPM – HCM: Child Incident Change Request form.
  • From the Children tab, click Add Existing to associate an already-created ticket to the parent.

When using Add Existing, all tickets across teams are displayed by default. To filter the list:

  • Go to FilterResponsible and enter BPM Ticket Assignment HCM to view tickets assigned to the BPM-HCM team.
  • If the desired ticket is not active, return to Filter and update Status to include additional values such as Closed, Cancelled, or others as needed.

Setting a Parent Ticket from a Child Ticket

A ticket can also be assigned as a child directly from the ticket itself:

  1. Open the ticket you want to convert into a child ticket.
  2. Select ActionsSet Parent.
  3. If you know the parent ticket ID, enter it directly and select it when it appears, or click the magnifying glass to search.
  4. Ensure the ticket selection scope is set to All Tickets (not My Tickets).
  5. Select the appropriate parent ticket, click Insert, then Save.

Once saved, the ticket will appear under the Children tab of the parent ticket and be included in parent-level tracking and reporting.

Back to Top

Details

Details

Article ID: 1384
Created
Sat 10/25/25 5:33 PM
Modified
Thu 6/18/26 4:57 PM