Time and Labor
Time Card Actions and What Validates When
Which buttons exist on a time card, which validations run on each, and the defaults that decide whether a worker hears about a problem before payroll does.
Learning objectives
- 1.Name the time card actions covered by validation and processing rules
- 2.Explain how Validate on Time Card Actions is configured and what the delivered defaults are
- 3.Explain what submitting does to the card status
- 4.State which validation behaviour is recorded as unconfirmed rather than taught
Why this matters
Time and Labor runs its entry validation when somebody presses a button, not on a schedule. Which button decides which validation runs, and therefore decides the moment a worker learns that what they recorded will not process. The same card, the same data and the same rules can be accepted or rejected depending on which of four buttons was pressed.
If you skip this: A configuration that validates only on Submit produces a card that saves cleanly all week and fails at the end of it, which is the most expensive moment to discover a problem.
What it is, why it exists, what breaks
What it is
The time card actions covered by validation and processing rules are Next, Save, Save and Close and Submit. Validation on the save buttons is configured from the Time Consumer Sets task, through the Validate on Time Card Actions field.
Why it exists
Placing the decision in the consumer set rather than in each rule means one setting governs when every consumer validation runs, rather than each rule carrying its own trigger.
What breaks without it
The delivered defaults are asymmetric. By default the delivered absence validations always start, while the delivered project and payroll validations do not. A tenant that assumes all delivered validations behave the same inherits a difference that was there before anyone configured anything.
Source: OTL-ACTION-060, OTL-ACTION-061
The four time card actions and what validates when
Four actions on one card, and one consumer-set field deciding which of them trigger validation. Listed in order: Next, then Save, then Save and Close, then Submit, then Validate on Time Card Actions, then Delivered defaults.
Four actions on a time card are covered by validation and processing rules: Next, Save, Save and Close, and Submit. Which validations run is not a property of the rules. It is set by the Validate on Time Card Actions field on the time consumer set, which chooses which actions trigger validation on save. The delivered defaults are asymmetric and this is the part worth remembering: by default the delivered absence validations always start, while the delivered project and payroll validations do not. A tenant that assumes every delivered validation behaves the same has inherited a difference that was there before anyone configured anything, and it shows up as a card that saves cleanly all week and fails at submission. Submitting is different in kind from the other three actions — it sets the time card status to Submitted and starts the approval workflow, so saving records and submitting requests. Oracle recommends selecting Submit and save for Project Costing so that people working on time cards learn immediately if they are saving time entries to closed projects. One question here is deliberately unanswered: whether the absence validation statement applies to Save alone or to both Save and Save and Close is ambiguous in the source and is recorded as needing confirmation rather than asserted.
What to take from this: Four buttons and one setting decide the whole picture. Submit is both an action and a status change, and it is the only one of the four that starts an approval workflow — so the difference between saving and submitting is the difference between a private note and a request.
Source: OTL-ACTION-060, OTL-SUBMIT-064
A week of clean saves and one failed submit
A worker records time all week, pressing Save as they go. Every save succeeds. On the Friday deadline they press Submit and the card fails validation against a project that closed earlier in the week.
- 1.Each save runs only the validations configured to run on the save buttons.
- 2.The delivered project and payroll validations do not start by default, so nothing flags the closed project during the week.
- 3.Submit runs the full set and the exception appears at the deadline.
- 4.The worker has to correct a card that had been accepted five times already.
Takeaway: Oracle recommends selecting Submit and save for Project Costing precisely so people working on time cards know immediately if they are saving time entries to closed projects. The recommendation exists because the default does not catch it for you.
Source: OTL-ACTION-062
Configuration model
Objects
Time Consumer Sets task
Where validation on the save buttons is configured, through the Validate on Time Card Actions field.
Risk if wrong: The set governs when every consumer validation runs, so a single field decides whether workers see problems early or at the deadline.
Validate on Time Card Actions
Chooses which of the time card actions trigger validation on save.
Risk if wrong: A card that saves cleanly every day and fails at submission, which is the failure the Oracle recommendation is aimed at.
Constraints
- The time card actions covered by validation and processing rules are Next, Save, Save and Close and Submit.
- Validation on the save buttons is configured using the Time Consumer Sets task, via the Validate on Time Card Actions field.
- By default the delivered absence validations always start, while the delivered project and payroll validations do not.
- Submitting sets the time card status to Submitted and starts the approval workflow.
Source: OTL-ACTION-060, OTL-ACTION-061, OTL-ACTION-062, OTL-SUBMIT-064
Common mistakes
Wrong: Assuming every delivered validation starts by default.
Symptom: Absence validations fire on every save while project and payroll validations do not, and the difference is mistaken for tenant misconfiguration.
Fix: The defaults are asymmetric and that is delivered behaviour: the absence validations always start, the project and payroll ones do not.
Wrong: Treating Save and Submit as the same action with different labels.
Symptom: A worker saves expecting the card to be on its way, and no approval was ever requested.
Fix: Submitting sets the status to Submitted and starts the approval workflow. Save records; Submit requests.
Wrong: Relying on the default to catch time saved against a closed project.
Symptom: Time entries to closed projects save without complaint and are discovered at submission.
Fix: Oracle recommends selecting Submit and save for Project Costing so the problem surfaces at the point of entry.
Diagnosing it
Symptom: A time card saves successfully but fails when it is submitted.
Category: workflow
- 1.
Is the failing validation one of the delivered project or payroll validations?
If no: Those do not start by default, so a save that passes and a submit that fails is the delivered behaviour rather than a fault.
Evidence to capture: The validation named in the submission exception
- 2.
Does Validate on Time Card Actions on the time consumer set include the action being pressed?
If no: That action does not run validation, which is the intended effect of the field.
Evidence to capture: The Validate on Time Card Actions value on the consumer set
- 3.
Was the card previously saved under a status where validation was not triggered?
If no: The card accumulated in a state that was never validated, which is consistent with the behaviour above.
Evidence to capture: The status the card held before submission and the actions used
Confirm: Confirm that the failure appears only on the actions included in Validate on Time Card Actions, and that the same card passes the actions it was saved with.
Recall
Name the time card actions that validation and processing rules cover, say where validation on the save buttons is configured, and state which delivered validations start by default.
Answer shape: Next, Save, Save and Close and Submit. Validation on the save buttons is configured from the Time Consumer Sets task through the Validate on Time Card Actions field. By default the delivered absence validations always start, while the delivered project and payroll validations do not.
Memory hook: Next, Save, Save and Close, Submit. Absence starts; project and payroll wait. Save records, Submit requests.
Source evidence
The action names, the configuration point for validation on the save buttons, the delivered defaults and the effect of submitting were read from the validation-by-action page on 2026-10-05, together with Oracle's own recommendation for Project Costing.
Release scope: FA Latest
Recorded gaps
- Claim OTL-ACTION-063 records that whether the absence validation statement applies to Save alone or to both Save and Save and Close is ambiguous in the retrieved markup and must be confirmed in the product before being taught. It is deliberately not asserted here and no lesson states either answer.
- The page presents the actions in a table; this lesson does not claim any behaviour of Next or Save and Close beyond their being covered by validation and processing rules.
Related concepts
- Consumer validationdepends on
The consumer validations are what the save-button setting governs, and their delivered defaults are asymmetric.
- Worker time entry profiledepends on
The entry profile governs which actions are enabled and who may perform them; this lesson is about what those actions trigger.
- Time consumer setdepends on
Validate on Time Card Actions is a field on the time consumer set, not on the rules themselves.
Self-check
An auto-graded assessment is attached to this lesson: assessment-otl-time-card-actions
Lesson progress
Checking your progress…