Identify permission needs

Assess the needs of your users & systems and evaluate what permissions to give them

This topic will help you decide which permissions to grant to your users and your systems. However, the central focus is on user permissions. Still, you can use this topic to assess your system needs as well.

At the end of this article, you’ll know exactly how to proceed. Optionally, you’ll have created a hierarchy of permissions to grant to your users and systems.

Prerequisites:

• You understand the difference between users and API keys
• You know what API keys are
• You are aware of the core functionalities of Inkit Render: Folders, Generated documents, webhooks, and so on
• You know the technical needs your systems have

Read more about:

• Users and API keys
• Organizing data with folders
• Subscribing to events with webhooks
• Pulling rendered PDFs from API

Create an overview of authority levels in your organization’s environment

While reading this section, please make use of the permissions overview reference topic.

Inkit Render has permissions in the categories of:

1. Folder management
2. Role management
3. API-keys management
4. User management
5. Webhook management

It is therefore prudent to think in terms of these categories.

A great way to separate authority in your environment is by creating authority levels. What this means is that you create layers of authority that form your authority hierarchy.

To do so, you must first identify what kind of users you will have in your environment.

So, consider these following questions and use them to create different user categories.

• Who will have access to your Inkit environment? What job titles do they have? Can you group them based on similar titles or functions?
• Within your organization, will you have people who should only view documents? If so, can you divide these people into regions? What about departments?
• Will you have administrators? What is the scope of their functions? For example, will they organize and create folders? Or will they also invite other members of your organization?
• Will you have developers in your organization? Should they have the admin role (access to all permissions), or should you limit their authority?
• Who should be in charge of managing roles? Should they also be in charge of managing API keys? What about webhooks? See if you can divide roles across the 5 core feature categories.

After answering these questions, you should be able to create an overview of different user categories. Try adding permissions to each user category. Use the permissions overview topic to find each permission.

For example, you may have a category called: US_banking_MD, consisting of bank employees from Maryland who should only view documents.

You could create a list of the category plus permissions:

US_banking_MD

• Renders.retrieve

Similarly, you could create a Maryland manager role:

US_manager_MD

• billing.invoices.list
• users.management
• users.retrieve
• users.update
• users.activate
• users.deactivate
• accounts.retrieve
• accounts.update

By doing so, you’ll make it easier for your organization to see which users will have which permissions. Spare yourself the headache of figuring out what authority people have.

Note: For an even more excellent overview of your permissions, you could divide your permissions into levels of authority.

For example, you may choose to create levels such as:

Clearance I:

• Renders.retrieve

Clearance II:

• billing.invoices.list
• users.management
• users.retrieve
• users.update
• users.activate
• users.deactivate
• accounts.retrieve
• accounts.update

Clearance III:

• All development permissions

Clearance IV:

• All permissions (admin role)

An advantage of using permissions in such clearance or authority layers is that it becomes easier to assign permissions to the right individual quickly.

You should now know how to identify your permission needs. You may choose to turn those needs into an overview. We highly recommend you do so.