Video - InEight Document Enhanced - Admin Access and Permissions

TRANSCRIPT

Welcome to InEight Document.

In this video, I will explain system access and permissions.

Whatever industry you're in. If you're using innate solutions, we know that access and security are important to you.

Your project probably has a number of different stakeholders who need different levels of access to documents, mail, forms, and other project critical information.

So how do you make sure everyone has the appropriate permissions, without spending all your time managing their security.

With InEight Document you have the flexibility to grant every user whatever security levels they need.

This video will focus on system access across and within modules.

Check out our Knowledge Library and Video Channel for more information specifically related to managing document access and permissions.

With much power comes much responsibility.

In a document has so many options for managing security and access, where do you start?

How can you take advantage of InEights flexibility yet keep it manageable for your projects.

In this video, we'll try to simplify things, By summarizing some of the most common security needs on projects?

Showing you how in a document meets those requirements, and providing some best practice recommendations.

Projects typically involve different kinds of stakeholders.

You might have the client, sometimes called the project owner.

The head or general contractor, subcontractors, and maybe additional third party consultants or even stakeholders like utility companies, or government departments.

Who are the different stakeholders on your project?

What are their different access needs? Do you need to grant access based on different stakeholder types, companies, roles, or perhaps a combination of all three?

The answers to these questions will really help you set up InEight Document security groups in the most efficient possible way.

Let's look at an example.

On this construction project, there is a head contractor, several subcontractors, and the client.

Each stakeholder type needs different levels of access to different modules.

Everyone needs at least personal access to send mail.

The subcontractors and head contractors will be uploading documents and sending transmitters.

The client just needs to be able to receive transmittals.

So that's the general rule for access on this project.

But what if there are exceptions to this? For instance, particular roles or users who need a unique type of access that does not fit in with these permissions.

One common example might be document controllers.

Unlike other users in their companies, all document controllers on this project may need full access to create, manage and receive documents and transmittals.

Whether they belong to the subcontractor, contractor, or client, As you can see here, the contractor and subcontractor document controllers have this access already.

However, this is not the case for the client.

This means the client's document controller needs a unique type of access, compared to the other users in their company.

So they would need their own collection of permissions.

Let's say later in the project, it's decided that all document controllers need a specific type of admin access delegated to them.

At the moment none of them have this access.

We can give the client document control of this level of access But if we want all document controllers to have this access, but not other users in the contractors or subcontract as companies, then they will need a separate collection of permissions.

In this case, it may sense now to group this collection of permissions by role, document controller, rather than by company or stakeholder type.

As you can see, things can get a little complicated, depending on your stakeholders and their different access needs.

This is why it can be a good idea to determine what different types of access are needed and group all users with the same needs together.

We call these security groups.

Looking at this project, we can create a subcontractor general user security group based on the subcontractor's stakeholder type. Since all these users require this access.

Over the course of the project, the main contractor's access needs evolve.

If they need access to packages and forms for instance, as well as the level of access granted to subcontractors, They will need to be grouped separately, so we can create a standard main contractor security group with this access.

This is an example of defining a security group by company.

Likewise, the client's users can be assigned to a security group by company.

Since they will only send and receive mail and receive documents and transmitters.

Lastly, we've seen how sometimes users across different companies with the same role, need the same levels of access.

We can create a security group called document controllers.

Something to keep in mind, you can add or remove people from security groups at any time, but each user can only be in one security group at a time.

Now you know how security groups work. Let's look at how to set up security groups in a document using the document controller example.

This is Jean, the primary admin for the main contractor on this project.

She is setting up the Document Controller Security Group.

Once she has created the group, she can add herself as the first user in the security group.

Since Jean is working with the subcontractors document controllers, She adds them to the security group.

Each of them needs to be able to upload documents and send her mail and transmitters.

As an administrator, Jean can grant them each full access to documents and transmittals here.

She gives them company access to mail as well. Since they often need to follow-up, other team members regarding project mail.

Since they all need the same type of access, it's fine to put them in the same security group, even though they're from different companies.

You can set up default access from this screen once.

Then any additional users added to that group automatically get that default access.

So if additional document controllers are brought on, you can quickly add them to this group as well.

One thing to note, although you can adjust certain access levels to registers and modules here at an individual level, in security groups with lots of users, it can get confusing.

So let's say Jean also wants to add the consulting architect's document controller Robin to a security group.

She knows Robin has slightly different access to the other document controllers.

For instance, no company access to mail.

So to avoid the risk of accidentally forgetting to tick this option, when saving it and accidentally reverting Robin's access to the default, She decides to create a separate security group for her.

Other examples of unique stakeholders who might have their own security group, include project directors, and primary administrators.

So now you know how to create security group and how defaults work. Let's go one level deeper and look at how access to different mail types is managed.

This is Amy. She's a project manager for the main contractor.

She receives some response to formal letters from the subcontractors and also drafts formal letters for the project director, who then sends them to the client.

On Amy's project, it's not appropriate for subcontractors to contact the client directly.

Fortunately, it's possible to configure InEight mail types in a way that ensures certain stakeholders do not communicate with each other.

Since the only way to send mail is by first selecting a mail type, communication between certain users can be prevented by limiting their access to different mail types.

For example, Amy could give subcontractors access to a mail type called subcontractor formal letter, and give clients access to a separate formal letter mail type called contractor formal letter.

As long as the subcontractors Security Group only has access to subcontractors' formal letter. And the client security group only has the ability to send and receive the contractor formal letter, They will not be able to use InEight to send mail to each other.

As you can see here, the subcontractors can send and receive other mail types too. But because the client doesn't have access to these same mail types, they won't be able to communicate directly with each other, as there is no overlap.

For that reason, Amy makes sure the document controller security group, which includes the document controllers for both the contractor, subcontractor and the client Only have the read access to formal letters.

Taking it to the next level, Since only, the project director for the main contractor Ray has permission to send contract formal letters to the client, he will need to be in a separate security group from everyone else, since only one level of access can be assigned per mail type.

These same principles apply to transmittal and form types too. However, most of the restrictions are generally based on male types.

Don't forget, of course, that InEight Mail is very secure.

Even if project users have company level access to a particular mail type, they will only ever see that mail type if it has been sent to their company.

These restrictions apply to everyone Even the primary administrator of InEight Document has no way of viewing mail if it was not sent to their company.

So in summary, how you manage security groups is largely determined by how granular the project user's access needs are. Particularly in relation to different types of mail, forms and transmitters.

These access needs might be grouped by stakeholder type company or roles.

There are generally going to be some exceptional cases where users need to belong to their own security group. But if you group common access as much as possible, that will make managing access as simple and maintainable as it can be.

Well, that's a quick introduction to managing system access within InEight Document.

If you're about to implement security groups or update access, Now it's time for you to have a think about what type of stakeholders you have on your project, what their access requirements are, and what kind of security groups you will need.

Thanks for watching.