is it possible to set up access role for each account can edit(add and delete, edit) and only see their own data(single SDR option as well as our sales) . also can i set up a higher role to see and edit the selected SDR(multiple) ? thank you
Yes, you can set up such a structure. There are a couple of ways to do it – you can control access by email address, or using “link keys” (e.g. UUID in the URL). You can also give more access, for example, to Owners of a document than to Editors, for an easy way to give full permissions to some privileged users.
In all cases, it’s important to read the article on access rules at Intro to access rules - Grist Help Center. For link keys, there is another article that gives simpler instructions: Link Keys Guide - Grist Help Center.
This is a complex feature, and it’s important to understand how it works, to reduce the risk of inadvertently giving more access than you intend. So there is no answer that’s much quicker than what the linked articles explain. If you have questions about the articles, or are running into issues with what you are trying, feel free to ask more specific questions.
I decided to tackle this problem as a learning exercise. I haven’t gotten much further than Dexter did.
I made a table (CRM) with the sales data. I made a second table (SalesRep) that just has the Rep’s name and a unique UUID.
In CRM, column SDR picks a sales rep out of the SalesRep table.
That’s as far as I’ve gotten. The CRM Card widget correctly displays the data of whichever record is selected. It does not care who the SDR is.
OK. I have most of the solution.
The Owner of the company has access to the tables and widgets “CRM Owner”, “CRM Owner Card”, and “SalesRep (Owner)”. They show everything.
The SalesReps have access to their own data in “CRM by SalesRep” and “CRM Card by SalesRep”. They get access to those widgets because the Owner has given them their own personal link.
I’m stumped on how to allow access to the two widgets only. The ACL seems to apply to tables, not widgets.
interesting. that’s our first thought too! good job. but for the salesrep, can they add the new row?
I don’t know. I have to get the permissions figured out first. I’m stumped on that.
Welcome to the forum, Mojosam! Really appreciate you sharing your learning exercise! In your case, the SDR’s are accessing the document via a link, rather than logging into Grist? If so, there’s a tutorial for setting permissions based on link UUID in our help center.
If the SDRs have a Grist login account and are a member of the team, you can set up access rules a little differently. I made a video walking you through how to do this.
Thank you for that. Permissions are very confusing. This clarifies a lot.
Yes, I wanted to share the document via link, because I didn’t want to use up my account’s two extra users with test accounts.
I’ve read almost the entire Help section, but not all of it has sunk in. I’ll experiment with this over the next couple of days.
Grist’s documentation, overall, is fairly good. The real problem is there are so few videos. I need to see this stuff in action to understand how it really works and fits together.
Thanks for that feedback! We’re definitely investing more into videos in the coming months. Subscribers to the Youtube channel get notifications when new videos go up, which may be helpful for you too.
Let me know if you run into trouble with link key permissions. If your intention is to eventually add sales reps as Grist team members, you can still add their emails now and “View As” the reps before you invite them to the document. It won’t cost you anything until they’re added to your team. In my video, you can see I view as the fake person Hugh, with the fake email email@example.com.