Enforce timesheets with a hard lock

When reminders are not enough, Enterprise organizations can escalate from visibility to enforcement. The strongest mode blocks day-to-day changes in the workspace until the person files their overdue timesheet, which makes “I’ll do it later” structurally impossible.

The three modes

The Enforcement mode picker lives in Organization Settings → Configuration → Timesheets, inside the Compliance enforcement panel:

• Warn: compliance is visible and reminders fire. Nothing is blocked. This is the default, and the only behavior below Enterprise.
• Soft block: adds a persistent banner for non-compliant users on every page. Still nothing blocked.
• Hard block: the server rejects changes to tasks, projects, and sprints for a non-compliant user until their prior week is filed.

What hard block actually blocks

The lock applies to write actions on tasks, projects, and sprints: creating, editing, moving, or deleting them. The locked person sees a banner explaining which week is missing, with a link to their timesheet.

Just as important is what is never blocked:

• Reading anything. Viewing projects, boards, reports, and timesheets always works; the gate fires only on changes.
• Logging and submitting timesheets. The way out is always open.
• Owners and Admins, by default. The Roles exempt from hard-lock chips let you change this, but keep at least one role exempt so someone can always unblock others.
• Integrations and agents using access tokens. Automation is never held hostage to a person’s timesheet.
• Anyone covered by a compliance exception, an exempt role, or a per-user exempt override.

Configure the lock

1. In the Compliance enforcement panel, select Hard block.

2. Set the Grace period: the number of days after the submission deadline before the lock fires. The default is 3 days, which gives people the weekend plus a buffer. The lock always targets a fully elapsed prior week, never the week in progress.

3. Leave Auto-unlock on submission on (the default) so the lock clears the moment the missing week is submitted. Turn it off only if you want an admin to clear locks manually via exceptions.

4. Adjust Roles exempt from hard-lock if needed, then save.

Caution

Roll this out in stages: run Warn for a few weeks, then Soft block, and only then Hard block. Pair the announcement with the deadline and reminder settings from Monitor timesheet compliance so nobody’s first contact with the policy is a locked task.

Best practices

1. Stage the rollout: Warn → Soft block → Hard block over 3+ months. Going straight to Hard block from no enforcement creates resentment and ticket storms. Each step lets the team adapt to the next.
2. Communicate the policy before turning it on. A 2-week heads-up email explaining “starting Date X, missing prior week blocks task edits” gives people time to build the habit. Surprise enforcement is poor practice.
3. Set the grace period to honor real-world patterns. 3 days is the default (Friday deadline + weekend = Monday lock). Longer grace defeats the discipline; shorter grace ignores weekends.
4. Keep Auto-unlock on submission ON. The point of the lock is to push the team to submit; turning auto-unlock off creates admin workload to manually unlock and breaks the feedback loop.
5. Make sure exempt roles aren’t a backdoor. If you exempt MEMBER role, hard-lock is toothless. Keep the exempt list to Owner + Admin (and maybe Portfolio Manager); test with a fake account before flipping live.

Troubleshooting / common pitfalls

• A person was locked who shouldn’t have been. Three causes: (a) the exemption (role, user-level, or exception) wasn’t configured before the lock fired; (b) the Grace period was set too short; (c) the compliance worker hadn’t recomputed since their exception was granted. Grant an exception or wait the worker cycle.
• Lock didn’t fire even though person is non-compliant. The gate is fail-open: if the compliance check errored, the change went through. Check the server logs for compliance errors. The gate is by design permissive on errors.
• Auto-unlock didn’t trigger after submit. Auto-unlock is on submission of the locked week. If the person submitted a different week, the lock stays. The banner names the specific week.
• Integrations stopped working. Check whether they’re using PAT-based auth (always exempt) or user-token auth (subject to the lock). Switch to PAT for true automation.
• The hard-lock banner is showing for someone with an exception. The exception may not yet cover the locked week. Backdate the exception to include it.

How this combines with other features

• Hard lock + Compliance settings. The lock reads compliance state continuously; changing the enforcement mode in settings takes effect within the worker cycle (one hour). See Monitor timesheet compliance.
• Hard lock + Exceptions. A covering exception releases the lock for that week. See Grant compliance exceptions.
• Hard lock + Escalation. Hard lock is the binary “all-or-nothing” approach; escalation chains add gradient (nudge → email manager → block). Some orgs use both: chain handles the spectrum, hard-lock kicks in at the worst level. See Run escalation chains.
• Hard lock + Audit logs. Every lock application and unlock writes an audit row. Useful for compliance audits and post-incident reviews. See Read audit logs.

Coming from another tool

Tool	Mapping
Microsoft Project Online	Resource workflow restrictions ≈ this concept
ServiceNow Compliance enforcement	Direct concept
Spreadsheet + manual locks	Onplana automates the enforcement
HRIS workflow gates	Onplana’s gates are workplace-tool side
Custom middleware	Onplana’s gate is server-side, can’t be bypassed

FAQs

What does a locked person experience? Their next attempted change fails with a clear message naming the missing week, their logged versus expected hours, and a link to the timesheet. A dismissable banner also appears across the app.

Is every lock recorded? Yes. Each block, and each unlock, writes an audit log entry, which is part of the evidence trail used by compliance evidence exports.

Can the lock fire because of a temporary outage or data glitch? The gate is built to fail open: if the compliance check itself errors, the change goes through rather than blocking work on a false positive.

Can I lock a specific project, not the whole org? Today the lock is org-wide based on per-person compliance. To lock specific project access, use project membership instead.

What about agents and external integrations? Always exempt — they authenticate via PATs, not user sessions. Integration work never blocks because someone is behind on hours.

Can I run a “soft” lock that warns but doesn’t actually block? That’s exactly what Soft block mode does: persistent banner, no actual blocking. Use it as the middle step in the rollout.

Related

• Grant compliance exceptions — the way out for legitimate absences
• Run escalation chains — gradient enforcement instead of binary
• Read audit logs — every lock event recorded