Transcription
Welcome back to Frappe Academy. Hope you are enjoying setting up ERPNext so far.
At Frappe Furniture, with the past two videos, we have been able to set up a few masters, create our own custom DocTypes and even customize them. All my employees have started to feel more comfortable using ERPNext. I am however concerned with the accessibility of the company information to the different users in my organization. I want that all my operational tasks even as small as order deliveries should be recorded in the system. At the same time I do not want my delivery associates to be able to view confidential customer information. I do not want my customer relationship manager to be able to view confidential company information. This is what I am going to set up in this video.
The permission management in ERPNext is typically done on three levels.
1. Based on a role wherein the users will be assigned certain roles with pre-decided permissions.
2. Based on documents wherein a user will have no access to any documents containing information that he or she is not directly involved with.
3. Based on fields within doctype wherein users will be restricted to view only certain elements of a doctype.
We are first going to see how permissions can be managed based on a role. Anna is an employee that I've just recruited at Frappe Furniture. She is a customer account manager and is going to be in charge of handling all the queries, feedback, and issues from her assigned customers. I will first create a user in the system by adding her email and name. All the other details can be added later. The moment the user is saved, a section will appears here called roles. In any organization, every employee has certain roles based on their job profile. This section will have a list of all such roles. You can also create a new role if needed. I have created a role called Customer Account Manager. I am going to assign Anna, the roles of a Sales User, Sales Manager and Customer Account Manager at Frappe Furniture. I will select Anna's roles here. The rights given to each role can also be checked here. There can also be certain users that are not a part of the organization, say, customers or auditors. Their specific roles can be assigned to them with limited permissions to system usage.
Now, how do we manage the permissions for any role. This can be done using the Role Permissions Manager. Here, you can define the permissions that users under every role will have on DocType. For example, I want my sales user to have rights to certain DocTypes like customer, sales order, opportunity and quotation. But, the set of permissions is going to be different for each job type. I can define this under Role Permissions Manager. Here, I can select the role and the DocType which I want to assign these permissions. The sales user already has a set of permissions for a sales order. These permissions will allow the user to read, create, edit, submit, delete, cancel, amend, share or print a DocType. The users can also be allowed to import or export the DocType, send it as an email or be able to set user permissions for this DocType. I can select or deselect the permissions that I want to be defined here. I will do the same for all the other DocTypes like customer, opportunity, rotation etc. using the Role Permissions Manager.
I can also set up permissions for a new role like for Customer Account Manager. Like Anna, I have different Customer Account Managers for different customers. Each of them have been assigned a similar set of roles. Every time a new Customer Account Manager joins a team, I have to assign these set of rules to them. A bit tedious, no? I have instead created a role profile here, and selected the roles that have to be assigned to every Customer Account Manager. So now, I can simply assign a role profile to each user at the time of their joining and all the rules under that profile will be automatically assigned to them.
We have seen how the permissions can be assigned using roles. Next, we will move on to Record Based Permissions. Since, I have given Anna the role of a sales user, she has all the relevant permissions to the DocType in the system. She can access the data related to customers. Like in this case, she is able to view Sales Orders related to all the customers, but she only handles two customers: Plethora Lifestyle Solutions and Global Builders. She shouldn't be able to see records related to other customers. To implement this, I am going to add a user permission for her. Here, I will add the user and under allow, I will add the doctype on which the data will be restricted. Under value, I will add the customer whose record she needs to access. Now, when Anna logs in, she will be able to see the Sales Transactions only with Plethora Lifestyle Solutions and Global Builders. We can also see a restricted button here. When she clicks on 'Restricted', Anna sees that her access is restricted to transactions from Plethora Lifestyle Solutions and Global Builders. This kind of access control is done for all the customer accounts that she will be managing in future. In a similar way, advanced controls can be used to restrict access. So if we want Anna to be able to see only the sales orders from another customer, Tanquil Hotels, that can be defined under advanced controls.
After setting up rule-based and record-based permissions, I will set up field-level permissions for my users. Sometimes, we may not want users to view all the details in a record. For example, Anna can see all the details of a customer feedback form, but I also have Tom, a Delivery Associate, who will need access to the same. A lot of my customers have some feedback on the delivery execution. Tom only needs to see the feedback on his delivery. He does not need to know the feedback rating and the total order value. I will configure this using Perm Level. Since this field appears in the table, we will first go to the Customer Feedback Order Details DocType, which is the DocType for the child table. Here, for the field Total Order Value, I will add a Perm Level 1. Similarly, I will add Perm Level 1 for Rating Field in the Customer Feedback DocType. Next, I will add Role Permissions for Customer Feedback DocType. For the Delivery Associate, I will add perm level 0 with only read permissions. Now, Tom cannot see the Total Order Value or the feedback rating on the customer feedback. On the other hand, I want Anna to be able to see the Total Order Value, so I will add the Role Permissions for her with Perm Level 1 and read and write permissions. When Anna logs into the system, she can see everything that Tom could see, along with the fields that had Perm Level 1.
After setting up permissions in the three ways as shown, we also have something called Role Permission for Pages and Reports. At Frappe Furniture, there are certain reports that carry financial information. I don't want anybody except my CXO's and Directors to see these reports. For this, I will look for Role Permission for Pages and Reports from the awesome bar. Herein, I will first select if the DocType is a page or a report. Next, I will select the report, say, Balance Sheet. I will select the roles that will have access to this report and save. Now, I have been assigned the System Manager role and since I do not have access to the balance sheet, I will not be able to find it in the system.
Lastly, let me introduce you to the share button for documents, using which you can allow a document to be temporarily shared with a user. Let's say, Tom needs to make a delivery where he has to take payment from the customer after he completes the delivery. Now, as per the permissions granted to his role, he will not be able to see any of the Sales Invoices. Though, for this delivery, he will need to access the Sales Invoice of this order so that he knows the order value. Here, instead of configuring the role permissions only for this particular scenario, I will use the share button. A list of all the users will be available here and you can select one to view a record. I will select Tom and give him read permissions. Now, when Tom logs in, he will be able to see the Sales Invoice and complete his delivery. Once the delivery is done, I can remove him from the sharing list. This way, the share button can be used to temporarily share specific documents with specific users in the organization. For all the other permission related requirements, the other options that we discussed previously can be used.
We hope with this video, you got a fair idea of how the user roles and permissions work in ERPNext. In the upcoming videos, we will explore the default settings in ERPNext. Meanwhile, you can go through the user manual to have a deeper understanding of ERPNext. Drop a comment to let us know your thoughts about the video. Hit the bell icon to subscribe to our channel and get notified about our upcoming videos.