The Request Intake & Categorization phase is the first step in the Process Innovation (PI) project lifecycle. Every request for a business process change, optimization, or new configuration begins with the submission of the PI: Project or Change Request form in TeamDynamix (TDX).
The Process Innovation 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 PI assessment data to ensure requests are properly routed, evaluated, prioritized, and tracked throughout the PI project and change request lifecycle.
Purpose
The purpose of this article is to outline:
- How to complete the PI Request Intake Form
- Which fields are completed by the PI 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 PI change management and project tracking processes.
Back to Top
Form Structure
The Request Intake Form is divided into two sections:
Internal PI Fields
Completed exclusively by the PI 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 PI 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 |
PI |
Dropdown |
Required. Tracks milestone progress (e.g., 0% Intake, 25% Discovery, 60% UAT). |
| Internal: HCM Prioritization Stage |
PI |
Dropdown |
Required. Intake status (Proposed, Discovery, Post-Discovery Review, Director Review). |
| Internal: Project Short Description |
PI |
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 |
PI |
Dropdown |
Required. Internal validation of payroll impact. |
| Internal: Functional Area |
PI |
Lookup |
Required. Primary HCM domain impacted. |
| Internal: Functional Area Approver’s Name |
PI |
Lookup |
Required. Primary decision-maker for the affected functional area, typically at the director level. |
| Internal: Executive Approver’s Name |
PI |
Lookup |
Required. Senior leader responsible for oversight of the affected functional area, typically a Senior Director, AVC, or equivalent. |
| Internal: Business Process |
PI |
Lookup |
Required. Workday business process impacted. |
| Internal: Business Capability |
PI |
Lookup |
Required. PI capability association (Project, Change, Service, Information) |
| Internal: Project Start Date |
PI |
Date |
Actual start date. |
| Internal: Estimated Project Due Date |
PI |
Date |
Estimated completion date. |
| Internal: Project Completion Date (Jira Close Date) |
PI |
Date |
Populated when related Jira/WSS work is closed. |
| Internal: Most Recent Update of Project Request |
PI |
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 |
PI |
Dropdown |
Primary outcome category (Compliance, Data Accuracy, Efficiency). Field is required once ticket is closed. |
| Internal: Outcome Narrative |
PI |
Text Area |
Narrative describing expected or realized outcome. Field is required once ticket is closed. |
| Internal: Responsible |
PI |
Lookup |
Assigned PI owner or group. Must be assigned to an individual once project or change begins. |
| Internal: Type |
PI |
Dropdown |
Internal classification used for reporting and prioritization. |
| Internal: Prioritization Recommendation |
PI |
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 |
PI |
Dropdown |
Institutional or operational impact assessment based on effort/impact matrix score. |
| Internal: Business Impact Narrative |
PI |
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 |
PI |
Dropdown |
Level of effort based on effort/impact matrix score (Light, Moderate, Heavy). |
| Internal: Effort Narrative |
PI |
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 |
PI |
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. |
Back to Top
Key Notes
- Submitters must complete all fields that populate based on their selections.
- Internal fields are maintained exclusively by the PI 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 PI: 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 PI: Child Incident Change Request and configured as an Incident service type so it can be selected and linked as a child ticket.
The PI 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
- Open the ticket that will be associated with a parent.
- Select Actions → Create Parent.
- When prompted to select a Major Incident form, choose PI: Project or Change Request.
- 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.
- 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 PI: 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 Filter → Responsible and enter BPM Ticket Assignment HCM to view tickets assigned to the PI 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:
- Open the ticket you want to convert into a child ticket.
- Select Actions → Set Parent.
- If you know the parent ticket ID, enter it directly and select it when it appears, or click the magnifying glass to search.
- Ensure the ticket selection scope is set to All Tickets (not My Tickets).
- 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