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)