Enter Time Business Process Guidelines

Administrator Guide

Overview

The Enter Time
business process controls worker time entry, submission, and approval. See Concept: Enter Time Business Process.

These are the sections in this topic:

Common Business Process Workflows

Subprocesses

The Enter Time
business process can initiate the Effort Certification
subprocess.

Prerequisites

You must first set up your environment to complete the Enter Time
business process successfully. See Steps: Set Up Time Tracking and Steps: Set Up Time Entry.

Security:

The Enter Time
business process security policy controls who can perform actions such as entering, submitting, and approving time. You can configure the policy to restrict these actions by role. Example: You can enable managers and Time Tracking administrators but not workers to use Quick Add to enter time.

You can create a custom security group for workers who are eligible for Time Tracking rather than using the Employee as Self security group. This gives you more granular control over who has access to time entry.

If you’re using time clocks, see Reference: Time Clock Event Security.

To view a list of applicable security domains, access the

Domain Security Policies for Functional Area

report and select the Time Tracking functional area.

To view the security domains for a specific securable item, access the

View Security for Securable Item

report.

Process Initiators

Initiation of the Enter Time
business process is controlled by the Enter Time
business process security policy. The process is initiated when:

Workers enter, edit, clear, or submit their time. Example: Using the

Enter My Time

report.

A person with the appropriate security permissions:

Manages time on behalf of a worker. Example: Using the

Enter Time for Worker

report.

Adjusts a worker’s calculated time. Example: Using the

Adjust Calculated Time

task.

The Enter Time
business process supports delegation so that managers or workers can delegate time entry and submission tasks to another user, such as an administrator.

Limitations

No cancellations, corrections, or rescinds: To make changes, users must directly edit, delete, or add time blocks and then resubmit the time for approval.

Time off: The autofill features within time entry don’t apply to time off entries. Time off is managed through Absence Management and the Request Time Off
business process.

Common Business Process Workflows

These are common workflow configuration paths for the Enter Time
business process, with the applicable steps for each flow.

To view the diagram of a business process workflow, click

View Diagram

on the

View Business Process Definition

page when you are editing the business process definition.

Path 1: Standard Approval

This is a common workflow where the worker enters and submits time. The time is then routed to the worker's manager for approval.

A: Initiation by Worker entering time

B: Initiation (Submit Time) by Worker

C: Action (Approve) by Manager

Completion

Path 2: Standard Approval with Certification

In this workflow, you require the worker to certify the time they submit. The time is then routed to the worker's manager for approval. See Steps: Set Up Effort Certification for Time Tracking.

A: Initiation by Worker entering time

B: Initiation (Submit Time)

C: Action (Certify Effort) by Worker

D: Action (Approve) by Manager

Completion

Path 3: Revise Time

When the approver sends back submitted time, the worker can correct their time and resubmit it as long as the time period is not locked.

A: Initiation by Worker entering time

B: Initiation (Submit Time) by Worker

C: Action (Send Back) by Manager

Initiation by Worker correcting time

B: Initiation (Submit Time) by Worker

C: Action (Approve) by Manager

Completion

Path 4: Manager and Cost Center Manager Approval

This path is used when an employee enters time against a cost center that is different from their home cost center, requiring approvals from both their direct manager and the manager of the cost center where the time was worked.

A: Initiation (Submit Time) by Worker

B: Action (Approve) by Manager and Cost Center Manager

Completion (once both managers approve)

Path 5: Timekeeper and Manager

In some organizations, a central person or team (Timekeeper) is responsible for reviewing time before or after the manager.

A: Initiation (Submit Time) by Worker

B: Action (Approve) by Timekeeper

C: Action (Approve) by Manager

Completion

Path 6: Multi-Level Project-Based Sequential Approvals

This workflow has multiple sequential approval steps. Time entries are first routed to a project manager and then to the worker's direct manager. The business process will only proceed to the second approval step after the first approver has completed their task.

A: Initiation by Worker entering time worked on a specific project

B: Initiation (Submit Time) by Worker

C: Action (Approve) by Project Manager

D: Action (Approve) by Manager

Completion

Path 7: Conditional Manager or Project Manager Approval

This path is common when non-project time is approved by the direct manager but project time must be approved by a project manager. This workflow uses conditions on the approval steps to check whether the time is project time or non-project time.

A: Initiation by Worker entering time

B: Initiation (Submit Time) by Worker

C: Action (Approve) by Manager if time is non-project time

D: Action (Approve) by Project Manager if time is project time

Completion (once both managers approve)

Path 8: Auto-Approval

This path is less common for hourly workers but may be used for specific populations or for tracking non-payable time. Workday is configured to automatically approve time upon submission.

A: Initiation by Worker entering time

B: Initiation (Submit Time) by Worker

Completion

Workflow Step Types

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

Initiation: Step Order
: Always the first step in the business process.
Group
: Initiation is not performed by a single role but is controlled by the business process security policy. This policy grants specific security groups permission to use different initiating actions. Common roles and groups that are granted initiation rights include: Employee as Self, Manager, Timekeeper, Time Tracking Administrator, and Delegate (a user who has been granted temporary authority to act on behalf of another user).
Security Domains
:
To enter and submit time: Employee as Self, Contingent Worker as Self, Manager: Modify access to Self-Service: Time Calendar
domain.
To enter time for worker: Manager, Timekeeper: Modify access to Worker Data: Time Calendar
domain.
To mass enter time: Timekeeper, Administrator: View access to Reports: Time Tracking
domain and Initiate access on the Reported Time Batch Event
business process security policy.
Step Type Guidelines
:
Best practices: Only grant initiating permissions to the security groups that absolutely need them.
Use Case: An organization wants workers to both enter and submit their time weekly and managers to only submit time when workers forget.
Example: In the Enter Time
business process security policy, you add the Employee as Self and Manager security groups to the Submit Time action. This enables workers to submit their own timesheets and enables their managers to access and submit timesheets on their behalf.

Action: Step Order
: Place anywhere after the Initiation
step. Example: You can place the Certify Effort
action step immediately after the Initiation
step. This requires the employee to certify their time as soon as they submit it. You can also place it after the Manager Approval
step, making the employee's certification the final action before the process completes.
Group
: Performed by Employee As Self and Contingent Worker As Self.
Security Domains (by Roles)
: Employee As Self or Contingent Worker As Self: View access on the Self-Service: Time Calendar
domain.
Specify
: Specify the subprocess that the step will trigger such as Certify Effort.
Step Type Guidelines
:
Best Practices: Use effort certification to require workers to certify their reported time when they submit it or after approval when others enter time on their behalf.
Use Case: A research university receives federal grants that require all personnel charging time to those grants to personally certify their effort on a weekly basis.
Condition Rule Guidelines
:
Best practices: Base your calculated fields on the Time Review Event business object.
Use Case: It’s company policy that when an hourly employee works more than 12 hours in a single day, a special Fatigue Management review process must be initiated. This process involves the employee's manager completing a To Do
step to acknowledge the long shift and confirm the employee is fit for their next shift.
Example: Create a To Do
step with instructions for the manager. Apply an entry condition for the step based on:
Calculated Field: Create a
Sum Related Instances
calculated field on the Time Review Event business object. This field will sum the total hours of all time blocks for each reported date.
Condition Rule: The condition rule for the Action
step would then check if the result of this calculated field is greater than 12 for any day within the submitted time period.
For more information, see Concept: Action Step.

Approval: Step Order
: There can be multiple Approval
steps in sequence or parallel.
Group
: Performed by a Manager, Timekeeper, Project Manager (for time associated with a specific project), Cost Center Manager (for time associated with a specific cost center), or Location Manager (for time associated with a specific location).
Security Domains (by Roles)
: You must specify the security group(s) responsible for the approval.
Step Type Guidelines
:
Best practice:
To prevent self-approval, use routing restrictions on the Approval
step. For example, if a Timekeeper who is also an hourly employee submits their own time, a routing restriction can exclude the initiator from the list of potential approvers, sending it to their manager instead.
Use condition rules to ensure that only relevant time entries are reviewed.
Use Case: You require a manager's approval for all submitted time, followed by the approval of the Payroll department for compliance or auditing purposes.
Example: Configure 2 sequential approval steps in the business process definition to route time entries first to the manager and then to the Payroll department.
Condition Rule Guidelines
:
Best practices:
Use the Time Review Event business object, which contains the context of the submitted time, including all the associated time blocks.
To evaluate specific attributes of a time entry, such as the time entry code, create calculated fields that refer to the time blocks in the time review event.
Use Case: You want to approve regular hours automatically but have managers approve overtime.
Example: Create a condition rule on the Approval
step that uses a calculated field to check if any time blocks in the time review event have an Overtime time entry code. If the condition is met, route to the manager for approval.
For more information, see Concept: Approval Step.

Completion: This step signifies that the main workflow is finished. Once the Completion
step is executed, the time entry is considered fully approved, and subsequent steps can run without holding up the core process.

Review the steps and identify which one should represent the final, required action for the time entry to be considered approved. This is often the final Approval
step in the sequence. Locate the row for this step in the grid, and from the related actions menu of that step, select
Business Process
>
Set to Completion
.

A business process can only have 1 Completion
step. If another step is already marked as the Completion
step, Workday will automatically uncheck it and apply the designation to the step you have just selected.

Integration

Integrations are most commonly used to initiate the process by loading external time data into Workday using an Enterprise Interface Builder (EIB) or a Studio integration.

Step Order

: The Integration
step can be placed at any point in the business process.

Group

: Performed by an Integration System User (ISU). An ISU isn’t a person but a special user account configured with the necessary security permissions to run the integration. Specify an ISU in the

Run As User

field during step configuration.

Security Domains (by Roles)

: The ISU must be granted permissions to the business process and the specific integration it needs to run.

Specify

: You must select the exact integration system or Workday web service that the step will launch.

Step Type Guidelines

Best practice:

Always use a dedicated ISU to run the integration. This ISU should be in a security group that has been granted the minimum required permissions on the necessary domains for the integration to execute successfully.

Trigger the integration after the time data is fully approved to ensure data consistency and prevent sending unapproved or pending data to downstream systems.

For integrations that may take a long time to run, configure them to run asynchronously to avoid delaying the completion of the business process.

Uses Cases: Sending approved project hours to an external project billing system.

Example: A manager approves a project worker’s time, which completes the Enter Time
business process. An Integration
step, placed after the Completion
step, triggers a custom Workday Studio integration, which generates a file containing the worker's ID, project ID, and the number of approved hours, and transmits this file to the external project billing system.

Condition Rule Guidelines

Best practice: Base the condition rule on data available in the Time Review Event business object.

Uses Cases: An organization sends time data to a third-party payroll provider, but only for hourly employees. Time submitted by salaried employees should not trigger the integration.

Example: Create a condition rule on the Integration
step that checks the Exempt from FLSA
field on the worker's profile. Configure the step to run only when the value of this field is "No".

For more information, see Concept: Integration Step and Create Integration (Step).

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. Workday allows you to 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 Actionable: The subject line should be direct and informative. Example: Action Required: Correct Your Time Entry.
The body of the notification should clearly state what has occurred and what action the recipient needs to take.

Target the Right Audience: Use security groups to ensure notifications are sent only to the relevant people. Over-notifying users can lead to them ignoring important messages.

Avoid Notification Fatigue: Don’t configure a custom notification for every step. Focus on key events that aren’t already covered by standard system notifications. Example: Notify users when an action is taken on their behalf or when a process requires correction.

Use Dynamic Content: Use report fields to include relevant data. Example: The worker's name, time period, and submission date. This provides context so that the user doesn't have to navigate to the task to understand the request.

Leverage Condition Rules: Use condition rules to create notifications for specific scenarios. Example: When a timesheet is sent back or initiated by a delegate.

Manage Notification Frequency: For less critical alerts, consider using a daily digest rather than immediate delivery to keep users from being overwhelmed. You can configure this in the

Edit Tenant Setup - Notifications

task.

Use Cases with Examples

Time Entry Sent Back for Correction:

Goal: Notify the worker so they can make the necessary changes.

Setup:

Trigger: On Entry of the Initiation
step

Recipient: Initiator.

Condition Rule: Create a condition rule that checks whether the Sent Back
or Manually Sent Back
field is true.

Example Message: Your time entry for the period [Time Period] has been sent back for correction. Please review the comments, make the necessary changes, and resubmit.

Time Submitted on Behalf of a Worker:

Goal: When a delegate or administrator enters and submits time for a worker, inform the worker that this action was taken on their behalf.

Setup:

Trigger: On Exit of the Initiation
step.

Recipient: Employee as Self.

Condition Rule: Create a rule to check whether the initiator of the process isn’t the worker for whom the time is being entered.

Example Message: Time has been submitted on your behalf by [Initiator's Name] for the period [Time Period].

Notification of Mass Approval by Payroll:

Goal: To meet a payroll deadline, a payroll administrator uses the

Mass Advance Business Process

task to approve time entries on behalf of managers who have not yet taken action. Notify the managers of this administrative approval.

Setup:

Trigger: On Manual Advance.

Recipient: The security group for the bypassed approver. Example: Manager.

Example Message: The time entry for [Worker Name] for the period [Time Period] was administratively approved to meet payroll processing deadlines.

Suppressing Approval Notifications with Mass Submit Time:

Goal: A payroll administrator uses an EIB and the

Mass Submit Time

report to upload and submit time for a large group of workers. Suppress standard approval notifications during mass operations to reduce unnecessary notifications to managers.

Setup:

Trigger: On the Approval
step.

Condition Rule: Modify the approval notification with a condition rule that prevents it from triggering if the initiator is a member of a specific security group. Example: Payroll Administrator.

Issues and Solutions

Issue	Cause and Solution
Can’t cancel an Enter Time business process event.	Cause: The Enter Time business process is designed to be iterative and does not support cancellation, correction, or rescinding. Solution: This is the expected behavior. You can modify or delete time blocks until the time period is locked. To see the available actions for a business process, use the Business Process Configuration Options report.
User able to enter time for a worker when they shouldn’t be able to.	Cause: The Enter Time business process security policy is not configured correctly. Solution: Review the audit records for the time entry to see who entered it and how. Examine the Enter Time business process security policy to identify which security groups have access to the task used to enter time. Check whether the user that entered the time is a member of any of the security groups. Adjust the security configuration as needed.
Time entries are unsubmitted after running the Mass Submit Time report.	Cause: This can be due to: A locked time entry period. Selecting the incorrect period. An improperly configured Enter Time business process security policy. Solution: Unlock the period if it is locked, ensure the correct period is selected when running the process, verify the configuration of any custom reports, and make sure the security group running the Mass Submit Time report is assigned to the Submit Time initiating action in the security policy.
Enter Time business process events aren’t displayed on the Worker History profile group of the worker's profile.	Cause: This is expected behavior. Solution: To view these events, use the Find Events report or the All Time Review Events data source.
Worker can view but not enter time on mobile.	Cause: Time is view only on mobile when the worker’s security group doesn’t have access to the Time Block Micro Edit initiating action. Solution: Add the worker’s security group to the Time Block Micro Edit initiating action of the Enter Time business process security policy, and ensure the security group has modify access to the Self-Service: Time Calendar domain.
Terminated workers can enter but not submit time during their termination week.	Cause: The security group they belong to doesn’t have access to the Submit Time action on the Enter Time Business Process Security Policy. Solution: Add the Terminee as Self security group to the Submit Time action on the security policy.