The submit action does nothing, spins indefinitely, or returns a validation message that names no field.
Start with how many people it affects
One worker, one group, or everyone — that single question maps onto the three places the fault can live, and answering it first is usually worth more than any amount of looking at the card itself. One worker points at their assignment. A group sharing a rule points at the rule. Everyone, for the same dates, points at the period.
Most likely causes
- A time-entry rule is failing rather than warning. A rule set to raise an error blocks submission; the same rule as a warning does not. This is also why the message is so unhelpful: an error raised by a rule does not have to name a field, so the card reports that something is wrong without saying where.
- The worker has no valid assignment for the period. A gap in assignment history leaves the day with nothing to charge time to. Three situations produce that gap and look identical from the card, with different fixes: an assignment that ended before the period closed, a change entered with a future effective date so it is not in force on the day being entered, and an assignment change part-way through the period, which is the one most often missed because the earlier days submitted normally.
- The payroll period is closed. Once closed, entries for the period are refused.
- A required attribute became mandatory. A layout change applies to cards that were already started, so a card opened before the change can fail on a field that did not exist when the worker began it. Nothing on the card says the layout moved underneath it.
What to check
- Whether the failure affects one worker, one group, or everyone — this separates a rule problem from an assignment problem quickly.
- Whether a draft card started before the change submits, versus a brand-new one for the same period. If a new card works and the old one does not, the problem is the old data rather than the configuration, and that single comparison is the fastest way to tell them apart.
- The worker's assignment history across the whole period, not only on the day that failed — a change mid-period is invisible if you look at one date.
- The period's status, and whether the same action succeeds for a date inside an open period.
What to capture before raising a ticket
- The worker number, and the exact time the submit was attempted.
- The period being entered, and the specific dates that fail.
- Whether a brand-new card for the same period submits.
Ask one affected person for the exact time and their worker number. Server-side logs are searchable that way and guesswork is not.
If none of the above explains it, raise a ticket and include what you checked. Reading this article cost you no hours.