I love that it’s now possible to lock entities!
Next step would be to allow using Automations and Workflow States (like Done) to lock entities automatically.
Thanks!
5 Likes
I am out of votes. But was just looking into doing this via automation. so +1
1 Like
Yeeeess needed. This is one of my primary use cases.
When a task is set to “done” it should be locked. In my case it would be to prevent anyone from adjusting sales commissions after a deal has closed. But really its just good practice.
This is a feature in Hubspot Deals object and works really well.
If you toggle on Control deal editing access you get these options:
You could add these settings to the field settings page for “State”. You can then define which user types can edit Entities at every given State.
If a user accidentally moves it to Complete stage and therefore can’t edit, they have to go to the Super Admins to ask them to unlock it (move it back to prior stage).
Which side note: it’s really confusing that the “Workflow” field is then called “State” after it’s created and its the same thing?
You might want to consider using per entity permissions, combined with auto-granting to make sure the right people can make the right edits at any given time.
Thanks Chris.
I had a good look through this but it seems like a really complicated workaround.
If I understand correctly I would have to create 2 entities for the same deal and link them:
- First entity is editable by everyone
- Second entity is editable by Admins
- Link both entities
Is that correct?
This is a bit confusing for the DB structure and I can see would probably(?) have unintended complications when trying to create reports or views. Maybe not I haven’t tried it yet but I’ll try to test it.
No need to create multiple entities.
You would create a field which links specific users to the entity based on it’s state. And then use permissions settings to grant access to the people who are linked.
In your example, you could link the user database to the State field, and then choose which users should have rights for that state. Then a formula in the Task db to get this field from the State, and use permissions to control access.
Of course, you need to make sure that users don’t get access to the database in general, and only via this field.
Wow yes this is exactly what I need.
I tried for a while to set it up but I still can’t get it to work.
It looks like State is the Workflow field of the Task db so how can I “link the user database to the State field”?
And then “choose which users should have rights for that state”? If the State is just a field, there is no mapping of State <> User, unless State is another database.
It’s like I just spent 30 minutes with one of those wooden brain teazer puzzles and I just couldn’t get the pieces to fit 
The Workflow field (and all single- or multi-select fields) are in fact ‘hidden’ databases, where each option is an entity. They support a lot of the same capabilities as true databases, including the ability to add relations. In this case, I added a relation from the State ‘database’ to the User database, and for each option (Open, In Progress, Done) I linked specific users.
If you watch the video, you can see that I open the specific State option with the name ‘Done’. This is possible by alt-clicking on the name. Sorry that it wasn’t clear. From here, you can add fields and relations as you would like.
Of course, in some cases, you might want the State field to be a true relation to a database (there are some things you can do with a true db that you can’t do with a select field db)
aha! got it now 
Thanks Chris, thats super helpful.
I even tried to increase the complexity and link it to user groups rather than specific people.
This is an interesting workaround, but in my use case, the people who need access are defined by the job (so whether it’s just the job manager, or all assignees, etc.). Therefore, this doesn’t seem possible using the workflow field. However, it’s also not possible as a formula field because sometimes I’m going to want to say ‘if this state, no user can edit’ and we can’t currently add null values (with no adding a ‘null’ user workaround because you can’t just add users).
An example of what I need to do (simplified a little): Make projects editable by only directors, admins, and the job manager when it’s a lead, editable by those plus assignees from active tasks when active, and view only by directors, admin, job manager once complete (no edit rights), visible to no one (except Fibery admin) once archived.
I’ll need to do similar on other databases, but I think Jobs will be the most complicated.
Any ideas?
You can relate the job state to your user group db twice, once to represent the groups who should be able to edit, and once for the groups who should be able to view. e.g.
Lead : Editors - Directors, Admins, Job Managers
Lead : Viewers - empty
Active : Editors - Directors, Admins, Job Managers
Active : Viewers - empty
Complete : Editors - empty
Complete : Viewers - Directors, Admins, Job Managers
Archived : Editors - empty
Archived : Viewers - empty
In addition, you can add a formula field to get the Assignees when the job is in the Active state:
Assignees.Filter([This Job].State.Name = "Active)
and grant Editor access via this field.
Thank you for the help getting my brain around this!
My Job Manager is a single person field on the job. Is there a way to get that to work? I cannot filter it like assignees because it’s not a collection.
Can you clarify the fields on your Jobs, and what user groups you have, just so I’m clear