Authorisation Concept
An overview and basis for decision-making
Introduction
primedocs is a template management and automation system that integrates seamlessly into Microsoft Office. It significantly simplifies and accelerates working with documents in Word, workbooks in Excel, e-mails in Outlook and presentations in PowerPoint. Furthermore, documents created with primedocs automatically stay "on brand" and therefore adhere more closely to the CI/CD (Corporate Identity / Corporate Design) of your company or organisation.
Because we know that there are many different organisational structures and ways of working, primedocs offers versatile and multi-layered authorisation functions. These authorisation options and structures are the subject of this page.
Authorisation Categories
We distinguish between different types of authorisations, which we will examine more closely later on:
Template and snippet authorisations: Here, authorisations are set on templates or snippets (or their categories) to control who is shown the respective template or snippet. In primedocs we can control with fine granularity who may see a template and who may not. The same applies to snippets and snippet categories (snippet folders). These authorisations are set per file object.
Administrator authorisations: In addition to the regular user authorisations, primedocs provides various extended user authorisations, as these enable different system and data accesses.
Template and Snippet Authorisations
Template Authorisations
Each template in primedocs can either be visible to all users or be restricted so that only certain users or members of a particular AD or primedocs group and/or particular organisational units can see a template. For example, a template can be made visible only to members of the "HR" or "Finance" team.
This visibility is linked to the profile. So if an employee has two profiles, one as a member of the OU "IT" and one as a member of the OU "Finance", then they would only see the "Finance" templates when they select the "Finance" profile; not with "IT". This dynamic way of presenting things makes it possible to always have a tidy, focused template selection depending on the role (which is controlled by means of group and OU membership).
To regulate the visibility of a template, you must have either "Layouter" admin rights or sys admin rights (more on this below). Read here how template authorisations work in detail: Template Permissions
Snippet Authorisations
The visibility of snippets can also be controlled in a comparable way. This visibility control, however, only concerns the "shared snippets", since the "personal snippets" are only visible to the respective users. With snippets, visibility can be controlled not only per snippet but also per snippet category. A snippet category is a folder that can also contain subfolders in order to structure the snippets. It can be defined per category who may see this category and all subcategories.
To regulate the visibility of a snippet/category and to edit a snippet, you must have either Snippet admin rights or sys admin rights (more on this below). Here, too, it can therefore be ensured that each user only sees those snippets (and categories) that are useful to them.
Read more about snippet authorisations here: Permissions
Administrator Authorisations
The administrator authorisations are managed in the Admin Dashboard.
They have already been described comprehensively in our technical documentation. Read the Permissions And Administration View, the individual administrator Permissions And Administration View or how the authorisations are set Permissions.
Tools: Windows groups or primedocs groups
In primedocs, the authorisations of templates and snippets (read and write rights) as well as organisational units are regulated by means of user groups. The groups either originate from the Active Directory (AD) (Windows groups) or they are created manually via the Admin Dashboard (primedocs groups).
Windows groups
There is the option of adding any groups from the Active Directory (AD). These AD groups are synchronised to primedocs. If data is changed in the AD, it is visible in primedocs after the next synchronisation, or immediately if a manual synchronisation is carried out from the Admin Dashboard.
As a rule, not all but only certain AD groups are chosen for synchronisation, since many AD groups have no relevance for primedocs.
primedocs groups
Often, however, there is no Windows group in the AD that could be used for the desired authorisation on templates, snippets or organisational units. Since it is usually undesirable to replicate a group in the AD just for primedocs, there is the option, via the Admin Dashboard and in addition to the AD groups, of also forming primedocs groups.
The primedocs groups can contain AD groups, so that a primedocs group can be formed from two or more AD groups. You can also add individual users to a primedocs group, although you must be aware that group membership here has to be maintained manually. Lastly, it is also possible to add other primedocs groups.
A common use of such primedocs groups is the formation of "power users" or "Layouters" in primedocs, that is, users who have extended rights or who build templates. The often cross-departmental users are frequently not already grouped in an AD group.
Concrete Use Cases
What might a concrete implementation look like if we were to make full use of these various authorisation options? Three examples follow which, although hypothetical, draw strongly on existing solutions (PS = PrimeSoft):
Simple setup: a single system administrator
In a simple setup, the templates/snippets are configured so that everyone sees everything and one person in the company can make adjustments everywhere.
This setup is suitable for a company with a small number of templates/snippets and with a small number of users, which is why it does not require a more complex authorisation structure. One person is appointed as primedocs sys admin, who maintains primedocs internally and commissions PrimeSoft with any template/snippet adjustments.
The simple setup thus concentrates on the use of templates and internal support, e.g. with regard to the maintenance of the organisational structure and assistance with profiles.
Such a setup could then look as follows:
| Role | Responsibility | Authorisation structure |
|---|---|---|
| SYS | customer side, one person | 1 user |
| ORG | customer side, especially if the OU structure has to be actively maintained - otherwise it can also be adjusted by PS. | Covered by SYS |
| USER | customer side, because PS usually has no direct access to the customer environment. | Covered by SYS |
| TEMPL | simple adjustments by SYS, template creation otherwise at PS | Covered by SYS, no Template admin |
| Snippet | management of the shared snippets by SYS or on request by PS | Covered by SYS, no Snippet admin |
Optimised setup: dedicated internal point of contact
An optimised setup is more multifaceted. The visibility of template groups/snippet categories as well as organisational units is regulated by authorisations per department (with corresponding AD groups), so that not all users can see all templates.
The templates/snippets as well as organisational units are largely managed independently by a dedicated group of users trained by PS, who also act as an internal point of contact for primedocs questions from users, so-called power users. Depending on the situation, you can either grant sys admin rights to all members of this department or assign a specific role to each member. In the first case, all members would then do everything, and in the second case, each member would thus automatically hold their own responsibility and area of duty (e.g. Org admin). This, however, depends on the company's internal processes. Depending on the size of this group, you can of course expand this structure further. This system can be planned further in such a way that only members of this department may create tickets with PS.
This setup is suitable for a company with a medium-sized or large number of users that tends to have many templates and snippets and wishes to manage these itself.
In the table below, this internal primedocs department organised by the company is abbreviated as "K-pd team".
Overview
| Role | Responsibility | Authorisation structure 1 | Authorisation structure 2 |
|---|---|---|---|
| SYS | customer side; K-pd team | All members of the K-pd team | 1 member of the K-pd team |
| ORG | customer side, especially if the OU structure has to be actively maintained. | Covered by SYS | 1 member of the K-pd team |
| USER | The K-pd team is the first point of contact for questions concerning profiles and profile shares. | Covered by SYS | 1 member of the K-pd team |
| TEMPL | All templates as well as template groups and their authorisations are created and edited by the K-pd team. In case of problems, the K-pd team contacts PS. | Covered by SYS | 1 member of the K-pd team; SYS admin authorises it on all templates. Alternatively: 2 members of the K-pd team (see below) |
| Snippet | All snippets as well as their authorisations are created and edited by the K-pd team. Alternatively: - The K-pd team edits only the template snippets. - The shared snippets are regulated via an alternative authorisation system (see below). | Covered by SYS | 1 member of the K-pd team Alternatively: - no member of the K-pd team (if only template snippets) |
Fully structured setup: responsible persons at every level
Introduction
A fully structured setup proceeds from the same prerequisites as the optimised setup, but is a different set of solutions. This setup is therefore also suitable for a company with a medium-sized or large number of users that tends to have many templates and snippets and wishes to manage these itself. Here, an authorisation system is required that is flexible and places the right people in the right place.
The visibility of template groups/snippet categories as well as organisational units is also regulated by authorisations per department, so that not all users can see all templates.
In contrast to the optimised setup, however, the administrator authorisations are now distributed in such a way that they are assigned, based on the organisational hierarchy, to several users per level, e.g. to division, department and/or team leaders. As a result, maintenance no longer has to take place centrally, but can take place in a decentralised, agile and flexible manner.
Example: Let us take an administration-oriented organisation as a concrete example: it has 5 organisational levels. Level 1 denotes the top management level, level 2 are divisions, level 3 are departments, level 4 are teams and level 5 is a further level for large teams. Now, one person from IT as well as from management is the sys admin (level 1).
Snippets
Shared snippets
Snippet categories are structured and named across the 5 levels in accordance with the hierarchy structure. All users of a level are authorised to see the snippets for their level. Dedicated users per level (e.g. per department) are authorised to manage the snippets.
Template snippets
Snippet categories are structured and named in accordance with template groups and their templates. Template administrators automatically receive access to all template snippets.
Concrete example: All users who belong to the OU "Division X" see the snippet category "Division X" in the snippet bar - the individual departments in X see the subcategories relevant to them, e.g. "Department X.Y".
Division X has a Snippet admin who sees all shared snippets but only takes care of the snippet category "Division X". They grant individual responsible persons modify rights on individual subcategories (e.g. category "Department X.Y"). Alternatively, this person is not a Snippet admin but merely has modify rights on these snippets.
Templates
The visibility of templates is regulated by means of an AD group that contains the users of a level. Each level has one or more dedicated users who maintain the templates of the corresponding level. Base templates that apply company-wide to all users are managed by a dedicated body in the company.
Concrete example: All users who belong to "Division X" see the templates in the template group "Division X - General". The users who belong to "Department X.Y" see the templates in the template group "Division X - Department X.Y". Alternatively, there can also be a template group "Division X" and individual departments or users are authorised on the individual templates.
Division X has a Template admin per department. They have modify rights on the corresponding templates and are therefore responsible for updating them. They collect change requests for templates of the entire department and carry them out. For new templates, they merely have to authorise the AD group "Department Y" or the corresponding primedocs OU and "All users" for reading.
This system can be planned further in such a way that only sys administrators may create tickets with PS.
ℹ️ Info Individual departments can of course also hand over their template editing to PS.
Overview
*Depending on the complexity of the organisational structure and the size of the company
| Role | Responsibility | Authorisation structure |
|---|---|---|
| SYS | customer side; users from all levels. In case of problems, collects requests from the internal responsible persons/admins and contacts PS. | *One user for the entire company or one user per level/department |
| ORG | customer side, especially if the OU structure has to be actively maintained. | *One user per level/department |
| USER | Per department there are so-called power users who act as the first point of contact for questions concerning profiles and profile shares for their department. | *One user per level/department |
| TEMPL | A department manages its own templates - this either by everyone or by dedicated authorised users. In case of problems, a higher internal point of contact (SYS) is contacted. | *One or more users per level/department |
| Snippet | A department manages its own snippet categories - this either by everyone or by dedicated authorised users. | *One or more users per level/department |
Conclusion
It is of course also possible to deploy a hybrid form of the concepts mentioned above. The system, however, also enables large companies to have organised access to templates and snippets for their users.
All of the systems mentioned above should be supplemented with a dedicated template approval process. This can encompass only the use of the 3 statuses of a template, or it can be made arbitrarily more complex through the use of a test and prod database, testing by the users and the subsequent import by an authorised user into the prod database. Note, however, that under certain circumstances separate authorisation systems can also be deployed for each database here.
A corresponding support process to PrimeSoft can also be derived based on your administration authorisations.
If your head is now spinning :face_with_spiral_eyes:: give us a call and let one of our supporters advise you on your specific situation!