Single user permissions can only be managed by a process or project admin.


Process Level Roles


There are three different process level roles in Midaxo that define user permissions across the whole process.

  1. Process admins control the whole environment and have full access to all projects in the process. They can create new processes and projects and manage users and their roles.
  2. Project creators work within one process. They can create new projects and assign new teams to them. When they create new projects, they can administer them.
  3. Project members work within their assigned projects, or even tasks (see section Task Level Permissions below). They need to be assigned to projects by a process admin or a project admin.

Process-Level Roles can be specified for users in the Users page.

Project Roles


On the project level, users can be either project admins or project members.


Project admins need to be assigned to projects by a process admin or other project admin. They can control all content of the project, add new project members (or admins) and specify user permissions on the task level.

Project members need to be assigned to projects by a process admin or a project admin. They can upload new content in the project and to tasks they have access to. Some of the project members may have admin rights on a limited subset of tasks. This is specified by the project admin.


Project roles can be adjusted in the Project Team tab in the project’s Overview page.


All new projects are hidden from all other (non-admin) users by default, so highly confidential projects can be safely added to the same pipeline. If a project has to be concealed from other admin users, a separate pipeline should be created for those projects.

Managing Task Level Permissions


Access to the contents of project tasks is controlled by task level permissions. Only project members are affected by these permissions.


Unless specified otherwise, the permission settings for tasks are inherited by the subtasks and all documents, issues, and communications attached to the tasks.


For example, an external legal advisor can be given access only to the legal due diligence tasks and related documents, or an HR integration team member can be given access only to the HR integration stream.


Task level permission settings:



Midaxo‘s user-specific permission management makes it easy to define permissions for any new user. 


What do the different permission levels mean?


There are five different permission levels. In short, they work like this:


No access

no_access.png

 
Users with this access rule set on a task cannot see the task, or the documents, events, and issues linked to it. 


Visible
visible-1.png

Users with this access rule can see the task title, its position in the task tree, and to whom the task is assigned only. This is because there is a subtask that has a higher permission level granted. This permission level cannot be set manually; it is set by the system to keep the task tree consistent. Users with this access rule will not be able to see any information about the task, nor the documents, issues, schedule, etc.


Read-only
read_only.png

Users with this access rule set on a task can see the task, documents, events, and issues linked to it. They can see all the details and they can download related documents, but they cannot modify anything.


Edit
edit.png

Users with this access rule set on a task can do everything the users with read-only access can, but they can also add new or modify existing documents, issues, and events. They are allowed to edit deal notes and goals and to change task status. They can link the documents, issues, and events to other tasks too, but they cannot delete them. Users with this permission level are not allowed to change the schedule (due date).


Admin
admin.png

Task admins can do everything the users with edit right can do, but they can also add new subtasks, delete documents, issues, or events, edit the guide, and change the schedule.


These permissions are effective only on the task level. Task admins currently cannot grant permissions to other users, nor modify the project team.

 

Permission Levels in Detail


Here is a more detailed overview of what the different permission levels will grant or deny users to do.


Task actions
No Access
Read Only
Edit
Admin
See the task title & position
No, but…*
Yes
Yes
Yes
See the task information (deal notes/goals, dependencies, guide)
No
Yes
Yes
Yes
Change status
No
No
Yes
Yes
Edit summary
No
No
Yes
Yes
Edit deal notes/goals
No
No
Yes
Yes
Edit task guide
No
No
No
Yes
Create subtask
No
No
No
Yes
Delete subtask
No
No
No
Yes
Move subtask
 No
No
No 
Yes 
Add dependencies
No
No
**
**
Delete dependencies
 No
No
No 
Yes 
See schedule
 No
 Yes
Yes 
Yes 
Export schedule
No 
Yes 
Yes 
Yes 
Edit schedule
 No
 No
 No
 Yes
Move the task
 No
 No
 No
***
Assign task owner
 No
 No
Yes
Yes 
Import tasks
 No
 No
 No
Excel
Recycle the task
 No
 No
 No
 Yes
Unrecycle the task
 No
 No
 No
****
Change task permissions
 No
 No
 No
****
Rename task
No 
 No
 No
 Yes

* If there is a sub task with a higher level access rule set, users can see the title and the position of the no-access task in the task tree. See the “Visible” permission level.

** The target task needs to be visible.

*** The user needs to be admin on both the parent task of the task that is being moved and on the task under which the task is going to be moved.

**** These functions are available to project admins, but may be available to task admins in a future release.

 

Document actions
No Access
Read Only
Edit
Admin
See documents
No
Yes
Yes
Yes
Read documents (download)
No
Yes
Yes
Yes
Add documents
No
No
Yes
Yes
Edit documents
No
No
Yes
Yes
Delete documents
No
No
No
Yes
Move documents
No
No
No
*
Mark a document as a key document
No
No
Yes
Yes

* Edit permission is required on the task to which the document is being moved

 


Issue-related actions
No Access
Read Only
Edit
Admin
Add issues (link issues to a new task)
No
No
Yes
Yes
Modify issues
No
No
Yes
Yes
Delete issues
No
No
No
Yes
Assign responsible
No
No
Yes
Yes
Unlink issues from a task
No
No
Yes
Yes
 

Event-related actions
No Access
Read Only
Edit
Admin
Add event (or link an event to a new issue)
No
No
Yes
Yes
Edit event
No
No
Yes
Yes
Delete event
No
No
No
Yes
Assign responsible
No
No
Yes
Yes
Change event status
No
No
Yes
Yes
Unlink event from a task
No
No
Yes
Yes

 


Activity-related actions
No Access
Read Only
Edit
Admin
View
No
Yes
Yes
Yes
Add comments/replies
No
No
Yes
Yes
Delete comments
No
No
No
Yes
See activities
No 
 Yes
Yes 
Yes 

 

Task permissions for groups of users


When a group is added to a project, all members of the group will be granted access to the project without needing to add them one by one to the project team. By default, the group will inherit the permissions from the “All users + groups” column in the Permissions view.  However, you can configure the permissions for each group the same way that you manage permissions for individual users.


If you need to configure permissions for someone that is already a member of a group, follow these steps:

  • Assign the individual user to your project from the “Project Team” view under the “Overview” tab
  • Open the Permissions and adjust the permissions for the individual as needed.


Note: Individual permissions always overrule Group Permissions. 


In the example below, Mike is a member of the Legal user group. His individual permissions for the first two task groups will override the permissions granted to the group.  Mike has Admin rights for Initial Target evaluation and No Access for Transaction/purchase phase.


 

Effortless Management of User Accounts


Only the process admin can add new users to the platform.


Managing users is effortless and automated as much as possible. Midaxo’s user page lists all users who have access to the platform, shows the general permission level (admin, project creator, or project member) and the contact details of each user, and lists all the projects that they belong to as team members.



 

Adding and Configuring New Accounts


Only the process admin can add new users to the process. Project admins can add new users to their project once those users have been added to the process.


Additional users can easily be added by filling in their basic information, after which the system sends an automatic welcome email with instructions for signing in. Users can update their own contact information and reset their password on a self-serve basis.

 

Removing Old Accounts


You can easily revoke users' access to certain projects. They can also be removed from Midaxo entirely, if necessary.


Single sign-on integration with active directory or other user directories is also possible, eliminating the need for user names and passwords. (Contact success@midaxo.com for more details.)  Former employees will no longer be able to sign in to Midaxo with their domain account once it is deactivated.


When you remove a user from Midaxo, all the important information they have put in Midaxo will remain there. However, tasks, issues, and events assigned to them will get unassigned. You will not see the user’s name in comments or in the Audit log.


Once removed, there is no way to activate the user account again. If you decide to add the user back, you will have to create a new user account.