Assign Costing Allocation Business Process Guidelines

Administrator Guide

Overview

The Assign Costing Allocation business process is a fundamental component of Workday's financial and payroll management capabilities. It's used to distribute a worker's earnings across various dimensions, known as worktags. These worktags can include, but are not limited to:

Cost Centers

Projects

Grants

Regions

Custom Organizations

You can execute this process as a standalone action or embed as a subprocess within other core Workday business processes, such as staffing changes. The primary function is to ensure that labor costs are accurately recorded and attributed to the correct financial and organizational entities within the business.

These are the sections in this topic:

Common Business Process Workflows

Common Business Workflow for Consolidated Approvals

Subprocesses

You can incorporate the Assign Costing Allocation
business process as a subprocess within several other key business processes. This enables you to make costing decisions at the time of the relevant event. Commonly, it's used as a subprocess for:

Hire

Change Job

Termination

Add Job

Create Position

Edit Position

Request Leave of Absence

Start International Assignment

Prerequisites

Before you can effectively use the Assign Costing Allocation
business process:

Enable Worktags for Cost Allocations: You must enable the relevant worktags such as Cost Center, Project, Grant for use in costing allocations. You can use the

Payroll Costing Allocation

section in the

Maintain Worktag Usage

task.

Configure the Business Process: You must configure the Assign Costing Allocation
business process to define the process steps, security, and any condition rules that apply.

Business Process Security: You must configure the security of the business process to control who can initiate, approve, and view costing allocations. This is managed through the business process security policy for Assign Costing Allocation
in the Core Payroll functional area.

Commonly secured actions and the roles/groups associated with them include:

Initiate: This action allows users to start the process.

Associated Roles/Groups: Typically granted to roles like HR Partner, Manager, or Payroll Partner. These are the users who are responsible for managing or correcting a worker's costing.

Approve: This action is for approving the proposed costing changes.

Associated Roles/Groups: Often includes Cost Center Manager, Grants Manager, or Finance Partner. The approval routing is often configured to go to the managers of the new
or proposed
costing worktags.

View All: This provides view-only access to the business process event.

Associated Roles/Groups: Granted to auditor roles like Finance Auditor or Payroll Auditor, as well as administrators who need to see the process history.

Domain Security: Users need permissions to the underlying data through various domain security policies.

Security:Worker Data: Payroll (Costing Override)
in the Core Payroll functional area.

Permissions Needed: View, Modify

Associated Roles and Groups: HR Partner, Manager, Payroll Administrator, Cost Center Manager

Description:Grants the ability to see and change costing allocation data on a worker's profile. Initiators and approvers require Modify access.

Security:Worker Data: Public Worker Reports
in the Core HCM functional area.

Permissions Needed: View

Associated Roles and Groups: All roles involved in the process.

Description: Provides access to basic, non-sensitive worker data (like name and position) necessary to identify the employee.

Security: Worker Data: Current Staffing Information
in the Core HCM functional area.

Permissions Needed: View

Associated Roles and Groups: All roles involved in the process.

Description: Grants access to view a worker's current position, job profile, and organizational assignments.

Security: Organization: Cost Center
in the Organizations functional area.

Permissions Needed: View

Associated Roles and Groups: All roles involved in the process.

Description: Enables users to see and select cost centers when making costing allocation changes. Similar domains for other worktags used in costing such as Region, Project are also required.

Security: Business Process Actions
in the Business Process functional area.

Permissions Needed: View

Associated Roles and Groups: All roles involved in the process.

Description: Secures the ability to see and click on the related action for Assign Costing Allocation from a worker's profile.

To apply these permissions, a security administrator must use the

Domain Security Policies for Functional Area

task, add the specified security groups to the domains with the required permissions, and then activate the pending security policy changes.

Process Initiators

You can initiate the Assign Costing Allocation
business process:

As part of another business process: When included as a step in a process like Hire
or Change Job
, the initiator of the parent process will trigger the costing allocation step. The task will then be routed to the appropriate role for completion.

As a standalone process: Users with the appropriate security permissions can initiate the

Assign Costing Allocation

task directly for a worker. The ability to do this is controlled by the business process security policy and domain security.

Typically, roles such as HR Administrator, Payroll Administrator, or Managers are granted the necessary security to initiate or act upon this business process.

Limitations

Change Job BP: When used as a sub-process of Change Job, costing allocations are applied at the Position level, not the Worker level. This is the designed behavior of the system.

Web Service vs. UI Task: The Assign Costing Allocation web service processes worktags in the order defined in the

Maintain Worktag Type Precedence

task. The user interface task doesn't adhere to this same precedence order.

Copying Allocations: When you use the functionality to copy an existing costing allocation, any attachments on the original allocation are not copied to the new one.

Routing on Duplicate Allocations: If a costing allocation is submitted without any changes (a duplicate), it may not trigger all expected approval steps, such as routing to a Grant Manager role.

Common Business Process Workflows

These are the common workflow configuration paths for the Assign Costing Allocation
business process, with the steps listed in their typical order.

To view the diagram of a business process workflow, click

View Diagram

on the

View Business Process Definition

page when you're editing the business process definition.

Path 1: Basic Approval

This is a straightforward workflow suitable for organizations where a single level of approval is sufficient.

A: Initiation

B: Approval

C: Completion

Path 2: Approval by Cost Center Manager

This path is common when financial accountability is managed at the cost center level.

A: Initiation

B: Approval by Cost Center Manager

C: Completion

Path 3: Multi-Level and Conditional Approvals

This more complex workflow is used in organizations with specific financial controls, such as those involving grants or special projects.

A: Initiation

B: Action (Review Costing Allocation Event Review Start)

C: Approval by Cost Center Manager

D: Approval by Payroll Administrator or Payroll Partner

E:Completion

Common Business Process Workflow for Consolidated Approvals

Path: Consolidated Approval within the Hire Process

This is a leading practice when you want a manager to approve all aspects of a new hire, including their job details, compensation, and costing in a single action.

A: Initiation

B: Action (Propose compensation)

C: Action (Assign Costing Allocation)

D: Consolidated Approval

E: Completion

Workflow Steps

These are the common step types used to build the business process workflow:

Initiation: Step Order
: Is always the first step.
Group
: Performed by HR Partner, Payroll Partner, Compensation Partner, Manager, Payroll Administrator
Step Type Guidelines
:
Best Practices:
Embed Contextual Data: Use the Maintain Step Related Worklets task on Step a to embed the Estimated Annual Compensation worklet. This allows the initiator to view the worker's current salary details directly on the costing allocation screen without navigating away.
Configure Required Worktags: Use the Maintain Worktag Usage task (configured for Payroll Costing Allocation) to specify which worktags are required. This ensures the initiator is prompted to enter necessary dimensions (such as Cost Center or Grant) immediately during initiation.
Integrate with Staffing Events: Add the Assign Costing Allocation
business process as a subprocess step in HCM workflows (such as Hire
or Change Job
) so that costing is captured at the moment of the HR transaction.
Use Case: An HR Partner is hiring an employee and must assign their labor costing overrides as part of the onboarding workflow.
Example: A new employee is hired with their salary split across two cost centers.
The HR Partner initiates the Hire event. Upon reaching the Assign Costing Allocation subprocess, the HR Partner is automatically prompted to enter costing details. Using the embedded Estimated Annual Compensation worklet on the page to confirm the worker's base pay, the HR Partner allocates 60% of the cost to Cost Center A and 40% to Cost Center B, then submits the step.
Condition Rule Guidelines
:
Best Practices:
Define Clear Entrance Criteria: Condition rules configured on the Initiation step act as entrance conditions (the "If" column). If the condition evaluates to false, the step (or subprocess) is skipped. Use this to avoid generating unnecessary inbox tasks for transactions that don't require costing updates.
Manage Leaves of Absence: If Assign Costing Allocation is triggered during a Leave of Absence, write a condition rule to skip it. This prevents the workflow from stalling due to Require Position validations that can occur when employees are on leave.
Use Case : Skipping the costing allocation subprocess during a Job Change if the worker is being transferred to a position that doesn't utilize costing overrides. For example, they will default to the standard organizational costing configuration.
Example : The organization requires costing overrides only for workers in specific job profiles or organizations. For all other employees, the default organizational costing should be utilized.
Conditional Rule Configuration:
Rule Name: Trigger Costing Allocation only for Grant-Funded Positions
Source External Field: Proposed Job Profile (or Proposed Position's funding source)
Relational Operator: any in selection list
Comparison Value: Select the list of grant-eligible job profiles.
Workflow: This rule is placed in the If column of the Assign Costing Allocation step on the parent Change Job business process. When a transfer occurs, Workday evaluates the job profile. If it's not grant-funded, the step is automatically skipped, letting the business process progress without user intervention.

Action: Step Order
:
Place anywhere after the Initiation
step.
Before Completion: Action steps that require user interaction, edit checks, or validation (such as completing compliance surveys or running automated budget checks before final approval) must be placed before the designated Completion Step.
Post-Completion: Action steps that don't block the core payroll assignment (like triggering downstream calculations, third-party integrations, or non-blocking To Do steps) can be placed after the completion step
Group
:
Central Administrative Roles: User-based groups such as Payroll Partners, Compensation Partners, or HR Partners.
Organizational/Restricted Roles: Role-based (constrained) security groups tied to the charged organizations, such as the Cost Center Manager, Grant Manager, or Project Manager.
Specify
:
For an Action step type, you must select the task or subprocess to trigger in the Specify column. In the Assign Costing Allocation business process, common specify options include:
Complete Questionnaire: Routes a questionnaire template to gather compliance certifications or additional business justification.
Check Budget (Staffing): Automatically triggers a budget validation check on the proposed costing overrides prior to approval routing.
Edit Additional Data: Directs the user to populate custom organization or costing-related fields.
Step Type Guidelines
:
Best Practices:
Understand the Review Limitation : By design in Workday, a Review action step within the Assign Costing Allocation workflow does not allow the assigned reviewer to edit or enrich the costing lines. Approvers and reviewers cannot make inline changes. If corrections are required, instruct them to use the Send Back button with clear comments.
Position Requirement for Budget Check: If you configure Check Budget (Staffing) as an action step, know that it will only trigger if both a Worker and a Position are selected during the costing entry. If a user enters costing at the worker-level only, the step is bypassed.
Validation Rules: To enforce custom system checks (e.g., preventing specific funding combinations), add validation conditions directly to the Initiation step (Step a) or the Action step by enabling the Enable Validation Conditions for Add Approvers
checkbox.
Use Case: An organization requires initiators who are allocating payroll expenses to federally funded grants to fill out an attestation acknowledging the spending guidelines of those specific sponsors.
Example: An HR Partner assigns a costing allocation that charges 50% of an employee's salary to Grant 4567.
Workflow:
The HR Partner submits the allocation (Step a).
The process hits Step b (an Action step specifying the Complete Questionnaire task).
Workday evaluates the entry condition and detects a Grant worktag.
The Complete Questionnaire task is routed to the initiator's Inbox to collect the federal compliance attestation before the process can advance to the final manager approval.
Condition Rule Guidelines
:
Best Practices:
Avoid Evaluating Historical Lines: Don't use the field Costing Allocation Proposed Organization Type (Non-Aggregated) in your condition rules. This field can evaluate historical, unchanged costing lines on the worker's record and cause routing errors. Instead, always use the field Worktag Types for New or Updated Costing Overrides to target only the newly introduced changes.
Test Rules Individually: Build and test your costing condition rules using the Test Rule task on active business process events to confirm they evaluate as expected.
Use Case: Automatically trigger a Check Budget (Staffing) action step only if the proposed costing allocation overrides include a Grant or Project worktag, while skipping budget checks for standard Cost Center allocations.
Example:
Rule Name: Costing Override Contains Grant or Project
Source External Field: Worktag Types for New or Updated Costing Overrides
Relational Operator: any in selection list
Comparison Value: Grant, Project
Step Configuration: Apply this rule as the Entry Condition in the If column for Step b (Action: Check Budget (Staffing)).
Expected Behavior: If the user updates costing overrides to charge a grant or project, the entry condition is met (True), and the budget check is executed. If they only assign standard cost centers, the condition is False, and the budget check step is skipped.

Approval: Step Order
: After the Initiation step (Step a) and any upfront Action steps (such as questionnaires or budget checks).
Group
:
Role-Based (Constrained) Groups: Tied directly to the organizations charged in the costing lines. Common roles include Cost Center Manager, Grant Manager, Project Manager, and Fund Manager.
Administrative (Unconstrained) Groups: Central teams such as Payroll Partners, HR Partners, or Compensation Partners who oversee the overall transaction
Step Type Guidelines
:
Best Practices:
Incorporate Fallback Routing: If an approval step routes to a role-based group (such as Cost Center Manager) and 1 of the proposed cost centers has no manager assigned, the step will go unassigned. Always configure a fallback routing group (such as a central Payroll Partner) to prevent the business process from stalling.
Leverage Workday's Approver Consolidation: Workday automatically consolidates routing requests. If a split costing allocation involves multiple organizations that happen to be managed by the same person, Workday consolidates the task and sends only one inbox notification to that manager.
Be Aware of Duplicate Costing Routing: If an initiator submits a costing allocation that matches their existing costing exactly (a duplicate submission), Workday may bypass certain role-based routings (like Grant role approvals) since no net change occurred, though routing compared to default cost centers may still fire.
Use Case: An organization requires that any time salary costs are shared across different departments, the respective managers of those charged departments must sign off on their portion of the financial commitment.
Example: An employee's costing allocation is updated to split their salary: 40% to Cost Center A (managed by Financials Manager) and 60% to Cost Center B (managed by HR Manager).
Workflow Execution: Workday routes the approval step to both Teresa and Logan. Because Configure Advanced Routing
is set to One User Per Group Per Organization Required
, both managers must approve their respective allocations in their Inbox before the business process successfully completes.
Condition Rule Guidelines
:
Best Practices:
Avoid Historical Evaluation Fields: Do not use the field Costing Allocation Proposed Organization Type (Non-Aggregated)
. This field evaluates historical, unchanged costing lines on the worker's record and can cause incorrect or unassigned routing.
Use the Correct Field for New Overrides: Always use the field Worktag Types for New or Updated Costing Overrides. This ensures the system only evaluates the new overrides being submitted in the active event
Use Case: Route an approval step to the Grant Manager only when a new or modified costing override explicitly charges a Grant worktag, avoiding unnecessary routing for standard cost-center-only allocations.
Example:
Rule Name: Contains New Grant Override
Source External Field: Worktag Types for New or Updated Costing Overrides
Relational Operator: any in selection list
Comparison Value: Grant
Step Configuration: Apply this rule in the If column for the Grant Manager Approval step.
Expected Behavior: If the initiator adds Grant 1002 to the costing overrides, the condition evaluates to True, and the step routes to the Grant Manager. If the initiator only changes the cost center, the condition evaluates to False, and the Grant Manager approval step is skipped entirely.

Completion: The completion step marks when the process finishes and all approvals and reviews must precede it to avoid validation errors, while post-completion actions (such as notifications or integrations) follow after; if unassigned, the very last step defaults as completion.

Integration

You can launch an integration for the Assign Costing Allocation business process from the Integration
step type.

Step Order

: The integration step usually occurs after all Approval steps and before the Completion step. This ensures that only fully approved and finalized costing allocation data is transmitted to external systems.

Group

: Performed by the system and requires you to assign a pre-configured Integration System User (ISU) that has the necessary security permissions to run the integration. An ISU is a special type of Workday user account used exclusively for running integrations, which provides a secure and auditable method for data exchange.

Specify

: You must select the specific integration that this step will launch. This could be a Core Connector, a custom Workday Studio integration, or an Enterprise Interface Builder (EIB).

Step Type Guidelines

Best Practices:

Build First: Always fully build, configure, and test the integration system. For example, the EIB or Studio integration before adding the Integration step to the business process.

Use an ISU: For security, auditing, and error handling, always use a dedicated Integration System User to execute the step.

Handle Failures: Use the Maintain Redirect related action on the step to configure what happens if the integration fails. Instead of letting the entire business process terminate, you can redirect the task to an administrator to investigate the failure.

Separate Generation and Delivery: For outbound integrations, it's a a leading practice to use a separate Service
step for Document Delivery. This separates the logic of creating the file from the logic of sending it, which simplifies troubleshooting.

Use Case: Automatically sending approved costing allocation changes to a downstream financial system to ensure payroll and financial reporting are aligned.

Example: A manager initiates a Costing Allocation event to split an employee's salary across 2 cost centers (Cost Center A - 60%, Cost Center B - 40%), which routes for Cost Center Manager approval. Once approved, Workday Studio extracts the employee ID, effective date, and allocation split into a formatted CSV file uploaded to the server. The financial system automatically retrieves this file to update records for the upcoming payroll run.

Condition Rule Guidelines

Best Practices:

Keep rules as simple as possible for easier maintenance. For highly complex routing, consider creating a separate, rule-based definition of the business process itself.

Thoroughly test your condition rules to ensure they behave as expected with different data scenarios.

Add comments to your condition rules to explain the business logic for future administrators.

Use Case: An organization has multiple financial systems. Costing allocations for employees in the USA and Canada need to be sent to ABC Financials, while allocations for employees in the UK and Ireland need to be sent to a separate XYZ system. Allocations for other countries do not require an integration.

Example: 2 separate Integration steps would be added to the business process definition.

Step 'd': Integration to ABC. Condition Rule: The rule checks the country of the employee's position. It runs only if Country IN (USA, Canada). The integration specified in this step sends the data to ABC Financials.

Step 'e': Integration to XYZ. Condition Rule: The rule checks the country of the employee's position. It runs only if Country IN (United Kingdom, Ireland). The integration specified in this step sends the data to XYZ.

If an allocation is processed for an employee in a different country for example, Mexico; neither condition rule is met, and both integration steps are skipped.

Notifications

System Notifications

System notifications are default alerts generated by Workday for business process events. You can view all system notifications on the

Notifications

tab of the business process. You can disable a specific notification, though it’s often better to manage notification preferences at the user level or use custom notifications for more targeted alerts. See Configure Business Process System Notifications.

Global notification settings are managed in the

Edit Tenant Setup - Notifications

task.

Custom Notifications

You can create custom notifications that can initiate on any step of the business process to alert users about events, required actions, or status changes. To create a notification, navigate to the respective step in your business process definition and from the related actions menu of that step, select

Business Process

Add Notification

. See Create Custom Notifications.

Guidelines and Best Practices: Be Clear and Concise: The subject and body of your notification should be easy to understand at a glance. Start the subject line with a clear identifier, such as Costing Allocation Change: [Employee Name].
Use Dynamic Fields: Leverage Workday's dynamic data fields to make notifications more informative. Instead of static text, include fields like Worker, Effective Date, Cost Center, and Distribution Percent. This provides recipients with all the necessary context without having to sign in to Workday.
Target the Right Audience: Over-notifying users can lead to them ignoring important messages. Carefully select the recipients. Use specific security groups (for example, Payroll Administrator, Project Manager) rather than broad groups. You can also send notifications to the Worker (the subject of the event) or their Manager.
Leverage Condition Rules: Use condition rules to control when a notification is sent. This is crucial for sending the right message at the right time and avoiding unnecessary alerts. For example, you can configure a notification to only trigger if the allocation is over a certain percentage or involves a specific department.
Disable System Notifications: If you create a custom notification to replace a standard system notification, remember to disable the corresponding system notification on the business process definition to avoid sending duplicate or conflicting messages.

Use Case with Examples: Use Case : Notify Payroll of an Approved Change
Scenario: The Payroll department needs to be aware of costing allocation changes before the next payroll run, especially if they need to perform manual verification or adjustments in a downstream system.
Example Setup:
Trigger: Upon Exit of the final approval step in the business process.
Recipients: The Payroll Administrator security group.
Message Content: A costing allocation for [Worker] has been fully approved and is effective [Effective Date]. Please review and ensure this change is reflected for the upcoming payroll cycle. You can view the details here: [Link to Business Process Event].

Issues and Solutions

Issue	Cause and Solution
Task is unassigned or routes to wrong approver.	Cause: The security group for the approval step (example: Cost Center Manager) is not assigned in the target organization, or the business process definition is routing based on the wrong context (example: initiator instead of the worker's organization). Solution: Ensure the required security roles are assigned in the relevant supervisory organizations. For routing issues, review the business process definition to confirm the approval step is configured to route based on the correct context (example: for the worker's organizations). Use View Process History for the event to diagnose where the routing failed.
Desired worktags (example: Project, Grant) are not available for selection.	Cause: The specific worktag type has not been enabled for use in payroll costing allocations. Solution: Use the Maintain Worktag Usage task. In the Payroll Costing Allocation section, add the desired worktag type (e.g., Project, Grant, Gift) to the list of Additional Worktags.
Initiator can't select any worker.	Cause: This often happens in a new or recently configured tenant. The root cause is typically that no worktags have been enabled for payroll costing at all. Solution: Use the Maintain Worktag Usage task and add at least 1 primary worktag (such as Cost Center) to the Payroll Costing Allocation section. Once a worktag is enabled, the worker prompt will become available
Payroll actuals don't match the costing allocation.	Cause: Workday's costing hierarchy is overriding the worker's costing allocation. A more specific costing instruction, such as a worktag entered on a time block, payroll input, or a one-time payment. This ttakes precedence over the general worker or position costing allocation Solution: This is often expected behavior. Review the Costing Allocation Priority. To troubleshoot, check the source of the earnings (example: timesheet, payroll input) to see if an overriding worktag was entered there. Remove the override at the source if the worker's default costing should be used
EIB Load succeeds but no allocations are created.	Cause: The employee already has an existing costing allocation for the same period, and the EIB is not configured to handle this overlap. Solution: In the EIB template, set the Replace Existing flag to Y. This instructs the EIB to end-date the existing allocation and replace it with the new one from the spreadsheet, preventing the overlap error.
Approval step is skipped.	Cause: A condition rule on the approval step is evaluating to false, causing the step to be skipped. This can also happen if a routing restriction (e.g., "Exclude Initiator") removes all potential approvers and no alternate routing is defined. Solution: Review the condition rule on the skipped step using the Business Process Condition Rule Tester to understand why it failed. If using routing restrictions, ensure an Alternate Routing (example to the excluded user's manager) is configured to prevent the step from being skipped when the primary approver is excluded.
Intercompany combination error.	Cause: The costing allocation combines a worker from one Company with a worktag (example: Cost Center) belonging to a different Company, and intercompany accounting is not properly configured or allowed for that combination. Solution: Verify that the correct Costing Override Company is specified on the allocation line to create a valid intercompany transaction. Ensure that the necessary intercompany setup has been configured in your financial system. If the combination is not intended, correct the worktag to align with the worker's company.
Condition rule routes based on old costing.	Cause: The condition rule on the business process is using a field that evaluates the worker's current, existing costing allocation instead of the new, proposed costing allocation within the current business process event. Solution: Modify the condition rule to use a field that specifically looks at the proposed transaction data. For example, instead of using a general field, use a context-aware field like Worktag Types for New or Updated Costing Overrides
Process is denied but Initiator is not notified.	Cause: The business process does not have a custom notification configured for the Denied status. The initiator may not know the process failed or why. Solution: Edit the business process definition and add a Custom Notification. Configure it to trigger on the Denied status, send to the Initiator, and include dynamic fields like the approver's comments ([Comment from the denial step]) to provide context.
Percentages do not total 100%	Cause: User error during data entry, or an EIB load where the distribution percentages for a single allocation do not sum to 1. Solution: For manual entry, Workday's UI provides a validation. For EIBs, implement a pre-load check in your spreadsheet to sum the percentages for each worker's allocation to ensure they total 100% before generating the EIB file. If loaded incorrectly, the event must be corrected or rescinded and re-entered.