Skip to content


This manual explains how to manage permissions in Yesplan. We divide this manual into three chapters:

  • A summary of the different concepts and general functioning of permissions in Yesplan.
  • A chapter in which the different configuration capabilities are discussed in detail.
  • A step-by-step plan to easily set up permissions within an organization.


Discover the specific steps to establish permissions in the guide for setting permissions.


The general functioning of permissions that is described here is not applicable for reports (templates and generated documents). The permissions system for these elements is explained in the Reports Manual.


Managing permissions in Yesplan is broken down into the various actions that a user can execute (their capabilities) and managing which users have access to which events, resources, prices, contacts and tasks.

Before going more deeply into how permissions are managed, we briefly explain a few basic concepts related to permissions in Yesplan.

User Capabilities§

It isn’t always advisable for a user to be allowed to execute every action or view all screens. In Yesplan, you can set who has the capability to perform various actions and to see certain screens and who does not.

This is determined via capabilities. If a user has a certain capability, then the corresponding action can be executed.

Granting Permissions§

Every Yesplan element (events, resources, contacts, etc.) has an owner. This owner is a Yesplan user. Initially the owner of an element will be the user that created this element. The owner of an element can be customized.

Every Yesplan user grants permissions to other users regarding what can happen to the elements that they own. These permissions determine who can read, write, clear, use, etc. this element. In other words, the owner of a certain element decides what can happen to that element in Yesplan.


Suspended users retain ownership of elements, so they continue to grant permissions. To prevent this from happening, you can transfer ownership to other users. See Suspending a user and Transferring and deleting ownership for more information.

Permission Templates§

A permission template is a set of capabilities and a description of the granted permissions.

These templates are used to describe the permissions of a certain group of users (such as ‘Administrators’) or a certain job title within an organization (such as ‘Planner’).

One or multiple permission templates can be awarded to a user. If a user was awarded multiple templates, his/her capabilities will be a union of all capabilities in these templates, and the granted permissions (for elements owned by the user) will also be a union of permissions determined by these templates.

Managing Permissions§

Managing Permission Templates§

Permission templates are managed in system settings under the “Users”, tab in the “Permission Templates” section. You can create, delete, duplicate and rename templates.

If you click on “Show Permissions”, a new screen will open where the capabilities and permissions for this template can be managed.

This screen consists of two parts:

  • At the top of the screen, there is a list of capabilities for the template.
  • At the bottom of the screen, you see the permissions that are granted to users that were assigned this template.

Managing Capabilities§

Capabilities are divided into three groups:

  • The types of elements that a user can create and the actions that can be executed on certain elements.
  • The tabs of various inspectors and modules that are visible.
  • The statuses that can be awarded to an event by a user.

Capabilities can easily be customized by activating or deactivating them. We will discuss each of these three groups in detail.

Creating Elements§

The left column shows the capabilities that a user receives to create elements or to execute certain actions. The following capabilities can be set:

  • Events: creating events.
  • Resources: creating resources.
  • Contacts: creating contacts.
  • Tasks: creating tasks.
  • Report templates: creating report templates.
  • Prices: creating prices for resources.
  • Mute conflicts: the capability to hide conflicts in the event calendar and the Teamplanner.
  • Unlock events: capability to unlock events that are ‘locked’.


Certain statuses can be marked as ‘locked’ in Yesplan. As soon as an event has this status, its name, date or location can no longer be changed, to prevent accidental changes. Changes are only possible by clicking on the lock next to the event. In order to open this lock, the user must have the capability to “unlock events”.

Visibility of Tabs and Teamplanner§

The middle column shows a list of tabs classified per inspector. Clicking on “Open” next to the name of the inspector shows all the tabs of that inspector.

You can determine whether the tab is visible for the user using the checkbox. If desired, you can customize the visibility of all tabs of an inspector at once by clicking on the checkbox next to the name of the inspector.

In this column, you can also determine whether the Teamplanner is visible in the navigation menu.


When you add new tabs to Yesplan they are, by default, not visible for users. You must activate these tabs under the template capabilities that are applicable for the users that must be able to view these tabs.

Use of Statuses§

The right column shows a list of statuses that were created in Yesplan for events. If a status is not activated, a user will not be able to award that status to an event.


The order of the statuses has a meaning. An event will often evolve from an option request to a fully scheduled and concluded event. The order of statuses can be determined via System Settings.

To move to the next status (a status that is lower in the list), a user must have the capability to use that status. To return to a previous status, the user must have the capability to use that previous status and to use all the intermediate statuses.

This functionality enables you to determine that a user can place an event in a ‘later’ status (and possibly skip certain statuses) but he/she cannot switch a planned event back to an option.

Granting Permissions§

The image above shows the area of the screen in which granted permissions are configured. This screen displays a table; each record corresponds with a user or a user group to whom permissions are granted. The columns of the table correspond with the type of permissions that are granted.

Records can be added to the table. You do this by clicking on “Add” at the bottom of the table. By double-clicking on the name of the user or user group (in the far-left column) in an existing row, you can customize to whom these permissions apply.

If the user to whom permissions were granted is deleted from the system, the name will appear in red.

Please note that it’s also possible to grant permissions to an entire user group simultaneously (see further).

A cell is shown for each type of element in Yesplan with checkboxes that determine the permissions for this type of element.

Please note that permissions for locations, placeholders and reports are not granted via a template. These permissions must be set per element (per location, placeholder or report).

The following permissions can be set for all elements:

  • View: a user or group of users can see this type of elements.
  • Edit: a user or group of users can customize this type of elements.
  • Delete: a user or group of users can delete this type of elements.
  • Edit Permissions: a user or group of users can customize the permissions for this type of elements.

Resources have the above-mentioned permissions as well as:

  • Book: the user or group of users can book the resource.
  • Edit Booking: the user or group of users can edit booked resources.
  • Delete Booking: the user or group of users can delete booked resources.

It is possible to activate all permissions in a certain record simultaneously by clicking on “Select All”, to the right of the record. Similarly, all permissions can be deactivated simultaneously by clicking on “Deselect All”. Finally, a record can be removed from the table by clicking on “Delete”.


It is important to understand that permissions are granted on the basis of an element’s owner. For example, imagine that we add this row of permissions to a permission template that we award to user Tim. In that case, Tim will be the one to grant permissions – as defined in this row – to the user Planner. In other words, Planner will be able to view, edit, delete, book and edit permissions for every resource owned by Tim. Tim’s bookings cannot be edited or deleted by Planner.

Permissions per Status§

For events, you can manage permissions per status. To add specific permissions for a certain status, click on “Add Status” in the header of the “Events” column.

If no specific permissions are determined for a status, the general permissions are applicable as defined in the “Events” column.

Permissions for Unavailabilities§

It is possible to indicate that a resource or location is unavailable during certain periods via the event calendar, the Teamplanner or the resource inspector. Unavailabilities do not have separate permissions in Yesplan; they follow the permissions of that resource. If a user can book a certain resource, then this user can also mark the resource as unavailable and delete unavailabilities.

A user can mark a human resource as unavailable, for a certain day or period, in the Teamplanner if the user has permission to book the human resource.

A user can mark a location as unavailable (‘lock the location’), for a certain day or period, in the event calendar if the user has permission to book in that location.

Granting Permissions to Different Users§

Permissions can be granted to different users and user groups. We will run through the capabilities from most general to most specific:

  • Everyone else: for permissions that are granted by a template or by a user, this record corresponds with the permissions for all users for whom no other, more specific record is defined. Please note that this record is always present and cannot be deleted.

  • Permissions for a certain user group: it is possible to grant permissions to a certain user group. These permissions are applicable for all users that are part of the user group. If a user is added to the group, this user will have the same permissions. If a user is deleted from the group, the permissions are no longer applicable for this user.

  • Permissions for a certain user: it is possible to grant permissions to a certain user. In the image above, a row of permissions can be added for the user ‘Administrator’.

In addition to these explicit users or groups of users, Yesplan also supports dynamic permissions. These are useful because you don’t have to name or repeat all users or user groups within Yesplan on each of the templates. We recommend that you only use these options in cases where a complex implementation of permissions is necessary since they make it harder for an administrator to discover precisely which permissions are applicable.

  • Owner: these permissions are applicable for the owner of an element.

    This allows us to express that a certain user receives permissions for an element, as soon as this user becomes the owner of that element (the user who creates an element is, by default, the owner).

    For example:

    • in template “General” we add a record for “Owner” in which the owner receives permission to view, edit and delete events
    • Jan and Sofie were both awarded the “General” template
    • Jan will be able to view, edit and delete all events that he creates, but not events that Sofie creates
    • Sofie will be able to view, edit and delete all events that she creates, but not events that Jan creates
  • Primary group of the owner: these permissions are applicable for the primary group of the owner of an element.

    This allows us to express that a certain user receives permissions for an element, as soon as this user is in the same user group as the primary group of the owner of that element.

    For example:

    • in template “General” we add a record for “Primary Group of Owner” in which the owner receives permission to view and edit events
    • Jan has “Planning theatre” as his primary group but is not a member of the “Planning dance” user group
    • Sofie has “Planning dance” as her primary group and is also a member of the “Planning theatre” user group
    • Jan and Sofie were both awarded the “General” template
    • Jan will be able to view and edit all events that were created by any user who has “Planning theatre” as their primary group, but not events created by Sofie (or by other users who have “Planning dance” as their primary group)
    • Sofie will be able to view and edit all events that were created by any user who has “Planning dance” as their primary group as well as events created by Jan (or by other users who have “Planning theatre” as their primary group)

    Please note that if we edit the primary group of a user, this also influences the permissions.

Since a user can belong to multiple user groups, and since Yesplan supports dynamic permissions like owner and primary group, it is possible that multiple rows within one permission template are applicable for a certain user. Yesplan will use the most specific permissions that are applicable when determining permissions for a user for a certain element.

The following rules are applied:

  • The most specific level is that of the user. This means that if there are user permissions, they will be applicable and the permissions for user groups and for everyone else will be ignored.

    For example, as soon as a record with explicit permissions for a user is included in the template, this record is always applicable. If the user is also the owner of the element and dynamic permissions for the owner were determined, then the combination of these owner permissions and any explicit permissions for the user is applicable.

  • If no explicit permissions for the user were included and the owner permissions are not applicable, Yesplan will look at the user group level. In this case, it is the combination of permissions for each of the users’ user groups that is applicable. If permissions for the primary group were also set and the user belongs to the primary group of the owner of this element, then these permissions will also be applicable, in combination with the other user group-specific permissions that apply.

  • If permissions at the user level and at the user group level do not apply, then the permissions for everyone else apply.

Awarding Permission Templates to Users§

Permission templates are awarded to users under system settings, under the “Users” tab, by the “Users” section. How this works is described in the System Settings Manual.

Please note that it is possible to award multiple permission templates to a user. In that case, the union of capabilities and granted permissions of all awarded templates will be applicable. In other words, as soon as one of the templates awards a certain capability or grants a permission, it will be applicable. When taking the union, the least strict permissions are granted.

Customizing User Permissions§

In addition to managing permissions based on permission templates that are granted to users, it is also possible to set capabilities and permissions separately per user. This can be done under system settings, under the “Users” tab, by the “Users” section. You click on “Show Permission Settings” in the record of a user.


In order not to complicate the management of permissions in Yesplan unnecessarily, we advise against using this option. Only use templates; this makes it easier to check where permissions are granted. An easy, step-by-step plan for implementing permissions is described below.

After clicking on “Show Permission Settings”, a screen will appear that is very similar to that for managing permissions on a permission template.

At the top of this screen, we see the user groups and permission templates that are applicable to the user. User groups or templates can be added to the user by clicking on “Add”; existing user groups or templates can be deleted by clicking on the “−” next to its name.

Under the list of user groups and templates, we see the user’s capabilities and granted permissions. These capabilities and permissions are a merger of the capabilities and permissions that the user was assigned via permission templates.

You can customize capabilities and permissions at the user level. Alterations that deviate are indicated by an asterisk behind the capability or the customized granted permissions. In the image above, we see that the user Planner cannot create contacts or tasks. These two capabilities were active on the templates applicable for this user so they are indicated as deviations, with an asterisk. Deviations with regard to the templates can be undone by clicking on “Reset”.

Permissions that are granted by a user can be customized in a similar manner. Deviations to the templates will be indicated with an asterisk. These deviations are undone by clicking on “Reset”. In the example above, you see that the user Planner can edit or delete events with the status ‘Option’ even though the templates did not grant permission for this. These permissions were customized at the user level; these settings are marked with an asterisk.

View the Permissions that Were Granted to a User§

In Yesplan, permissions are based on the concept that a user grants permissions to other users either explicitly or via permission templates. To know which permissions were granted to a specific user - what their acquired permissions are - you can click on “Show Permission Settings” in the far-right column in the list of users (found under system settings, under the “Users” tab, by the “Users” section)

At the bottom of the screen you see a list of permissions that were granted to that user.

Each record shows a specific permission; the columns show the various types of Yesplan elements. Each cell in this table contains a list of users that grant the corresponding permission for the corresponding element. For example, we see that Planner can view events owned by himself or by Administrator, and can only delete prices owned by Administrator.

Customizing Element Permissions§

You can customize element permissions. These permissions will replace the permissions granted by the owner of the element. Element permissions are customized via the “Permissions” tab on the inspector of that element. This is possible for events, resources, locations, contacts and tasks.


  • Locations and placeholders are not granted permissions through a permission template: their permissions are always managed through the inspector.
  • Reports are shared with other users, and at the time of sharing it is decided what the other users can do with them (view, edit or delete). This is explained in the Reports Manual.
  • An administrator always sees all elements, even if he does not have permission to view them.

The permissions for an individual element are managed as follows:

  • At the top you see the element’s owner. You can change this owner by clicking on “Change Owner”. This can be handy if the owner changes job titles or leaves the organization.
  • Under the owner, you see a table of various user groups and users who received permissions for this element. Permissions for the different users of this element can be customized via checkboxes.
  • This table will always contain a “Me” record. These are the permissions of the user who is signed in. To avoid inadvertent changes to this record, you must click on the lock before making changes.
  • You can add specific permissions for other user groups or users by clicking “Add User Group or User” below the table.
  • You can delete added records again. It is not possible to delete existing records with permissions for a certain user group or user, but you can change their permissions if you have permission to do so.

Permissions for Events and Event Groups§

Events and event groups have a central role in Yesplan. There are, however, a few things to bear in mind when managing their permissions through the inspector:

  • The permissions for events and event groups are managed separately for every element, given that every event can have a different owner.
  • If you deselect a person’s permissions to “View” an event, that person will be able to see the event in the event calendar, but it will be shown under the name “[Undisclosed]”. The tabs for that event will appear empty for that user.
  • If you deselect a person’s permissions to “View” an event group, the group will be shown under the name “[Undisclosed]” for that user. In the inspector, the tabs will appear empty for the event group in question. However, events in that group will remain visible in the calendar, and all tabs in the inspector will be accessible for those events.


The inheritance of custom data is an important principle in event groups, but this does not apply for the management of their permissions. If, for example, you change the permissions for an event group under the “Permissions” tab, the events in that group will not adopt the changes automatically: in other words you will have to change the permissions for every event separately.

Permissions for Locations and Placeholders§

For permission templates and permissions that are granted by users, it is not possible to manage permissions for locations and placeholders. Locations and placeholders are regarded as special resources; permissions for locations and placeholders are determined per element.

Permissions for Locations§

Permissions for locations are managed under system settings, under the “Resources” tab, by the “Locations” section. Then you open the location inspector by clicking on the name of the location. You can manage permissions on the “Permissions” tab of this inspector. Managing the permissions for a location is similar to managing element permissions, with the exception that a location has a user group as an owner rather than a user. This makes it easier to link locations to certain user groups.

Please note that you can also open the location inspector from the event calendar by clicking on the name of the location (in the header of the column).

Permissions for Placeholders§

Placeholders do not have an owner and can be read and booked by every Yesplan user. Only administrators can change the placeholder.

It is not advisable to allow every Yesplan user to alter the prices of a placeholder; that’s why price permissions are managed. Placeholder permissions are managed under system settings, under the “Resources” tab, by the “Groups & Roles” section. Then you open the placeholder inspector by clicking on “Inspect” in the row of a certain role. You can manage permissions on the “Permissions for Prices” tab on this inspector.

Please note that you can also open the placeholder inspector from an event inspector if it has a booking for that placeholder. Open the booking inspector for that placeholder first (by clicking on the name), then open the placeholder inspector (by clicking on the button at the bottom of the booking inspector).