TL;DR
- One Jobs table, one User field, and each cleaner sees only the jobs they are assigned to. No duplicate tables, no per-person workspaces, no automation copying records around.
- Point the table's Record Lock at the Assigned Cleaner field. Read lock hides everyone else's jobs. Write lock shows the whole schedule but only lets a cleaner edit their own.
- Admins always see everything, and automations are never restricted, so the office view and your scheduling rules keep working.
- The limits are real and worth knowing first: one locking field per table, and that field cannot hold multiple users. Anything more complicated, like "the cleaner plus their supervisor", needs a validation rule instead.
- It is included on every plan, starting at $29 a month with unlimited users.
A small cleaning company needs one place to manage its customer jobs.
But cleaners may need customer addresses, access instructions and job notes. They should not automatically gain access to every job in the system.
Here is how that can be handled using Record Lock in InfoLobby.
- Customers
- Inquiries
- Quotations
- Sites
- Jobs
Once a quotation is accepted, the customer's site is added and cleaning jobs can be scheduled against it. Each job is assigned to a cleaner.
The operational workflow is simple:
Inquiry, Quotation, Site, Job, Completion
All cleaners work from the same Jobs table, while Record Lock determines which jobs each person can access.
The setup
The Jobs table contains:
- Job Reference
- Customer
- Site
- Scheduled Date
- Start Time
- Duration
- Assigned Cleaner
- Status
- Completion Notes
Access to each job is controlled through the Assigned Cleaner field.
It is a single-user field connected to the InfoLobby user responsible for completing the job.
I created several jobs across different customer sites, with some assigned to Thaha and others assigned to Maria.
As an administrator, I could see every job in the schedule: 37 records across the month.
Showing each cleaner only their jobs
Record Lock is set on the User field itself, not in a separate permissions screen. On the Jobs table's Configure screen, I opened the Fields tab, clicked Assigned Cleaner, and set Record Lock to "See only their own records".
When Maria opened the Jobs table, she saw only the jobs where she was the assigned cleaner. Jobs assigned to Thaha were not visible to her.
Thaha used the same table and the same saved view, and saw only his own 20 jobs. Same table, same view, two different schedules.
There is no separate Jobs table for each cleaner and no automation creating private copies of records. Access is decided directly from the user assigned to each job.
One consequence to plan for: once a table is locked, ordinary members can no longer change the locking field. New jobs are assigned to whoever creates them, and reassigning a job is an admin action. That is what makes the lock mean anything. If Maria could edit Assigned Cleaner, she could hand herself Thaha's jobs, or make her own disappear.
Read lock and write lock are different
Record Lock can control whether users can read or write a record.
With a read lock, a cleaner can only see jobs assigned to them. That makes sense when job records contain customer addresses, access instructions or other information that unrelated staff should not see.
A write lock works differently. Maria can see the wider schedule, but she can update only jobs assigned to her. She could change her own job from Scheduled to Completed and add completion notes. When she opened a job assigned to Thaha, it stayed read-only, with nothing to type into and no Save button.
The two configurations support different operating models:
| Record Lock | Cleaner experience |
|---|---|
| Read | Sees only jobs assigned to them |
| Write | Sees the wider schedule but edits only their jobs |
Pick write lock when the team benefits from seeing the whole week, for example to cover for each other. Pick read lock when the record itself holds something a cleaner has no business reading for a site they are not visiting.
One schedule without exposing every job
Without row-level permissions, small businesses usually end up choosing between two poor approaches.
They either give staff access to the complete operational table or create separate views, tables and workspaces for different people. Both become harder to control as the team grows. It is the same wall people hit when they try to run a client portal or an internal team hub by giving everyone their own workspace: it works for three, and it is unmanageable at thirty.
With Record Lock, the cleaning company can keep one Jobs table while access follows the Assigned Cleaner field.
The owner sees the complete operation. Each cleaner sees or edits only the work they are responsible for.
Current limits
There are two important limits:
- Each table can use one user field for Record Lock.
- The selected field must contain a single user.
That works for direct ownership rules such as assigning one cleaning job to one cleaner.
More complex rules, such as giving access to both the assigned cleaner and their supervisor, require a validation rule. I will cover that separately.
Two more things worth knowing before you turn it on. Under a read lock, a job with Assigned Cleaner empty is visible to admins only, so an unassigned job silently belongs to nobody. And automations are not restricted at all, which is the point: a flow that reassigns tomorrow's jobs when someone calls in sick keeps working exactly as before.
Row-level permissions without an enterprise plan
Row-level access is often treated as an advanced feature or reserved for expensive plans.
In this example, the rule is straightforward:
If you are the cleaner assigned to this job, you can access it.
Record Lock is included on every InfoLobby plan, and plans start at $29 a month with unlimited users. See plans and pricing for the rest of the limits.
One Jobs table. Multiple cleaners. Different records for each person. No duplicated tables, no private copies and no enterprise subscription required.
FAQ
Can a job be assigned to two cleaners at once?
Not with Record Lock. The locking field has to be a single-user field, because "assigned to several people" changes what the lock means. If two cleaners genuinely share a job, keep the table unlocked and enforce access with a validation rule instead.
Do admins get locked out of their own table?
No. Workspace admins always see and edit every record, and they are the only people who can reassign one. See Record Lock for the full behaviour.
Will my automations break when I turn the lock on?
No. A flow is not a person, so it is never restricted. The same goes for PHPScript, imports, and the scheduled jobs that create next week's cleaning schedule.
What happens to jobs that have no cleaner assigned?
Under a read lock they are visible to admins only. Fill in the field before you lock an existing table, or plan to assign the leftovers afterwards.