A Closer Look at Data Permissions (System Objects)

Modified on Fri, 11 Apr at 8:14 AM

In this article:



System Objects represent various parts of the Actionstep system that you can set permissions for. This includes any new action types or data collections that you create.




Getting to Know the System Object Security Editor

System Object permissions are controlled through the System Object Security Editor. On this page, when you select a System Role and System Object, Actionstep displays a list specific functions, like deleting documents or viewing emails, that can have permissions assigned to them, limiting which of your users can interact with that feature. Some System Object permissions are specific (e.g., one might provide the ability to overwrite a rate sheet that is used in a time sheet) but most objects represent simple options that allow a user to either read, create, edit or delete certain things.



To access the System Object Security Editor:

  • In Actionstep, go to Admin > Users & Permissions > Data Permissions.


 

A. System Role: Shows the specific role in your system that you are adjusting permissions for.


B. System Object: Shows the area or feature of your Actionstep system you are granting or restricting access to. 


C. Enabled permission: Shows a specific permission that has been enabled for the selected System Role. (Note the green checkmark next to the permission name.)


D. Additional configurations: Shows additional settings associated with this permission that you can configure for the selected System Role. Click OR to add more conditions. 


E. Disabled permission: Shows a specific permission that will not be available for the selected System Role. (Note the grayed out appearance of the permission name.)


F. Save / Prev / Next / Close: Provides options for saving your changes and moving to the next or previous System Object in your list.

 

 

In the following example:

  • The System Role (Paralegal) can list or view matters based on the System Object Action Type Appeal
  • They can also modify matters based on the Appeal action type. 
  • However, they cannot create any new Appeal-based matters or delete any Appeal-based matters. 
  • Finally, they cannot restrict access to an Appeal-based matter.

To explain these permissions further: 

  • Selecting can_read allows users assigned to this role to view matters of this type in any list or view that would display them. They can also search for and open any matter of this type using the global Search box.
  • Selecting can_create allows users assigned to this role to create a new matter or based on this matter type.
  • Selecting can_modify allows users assigned to this role to make changes to a matter once the matter is opened.
  • Selecting can_delete allows users assigned to this role to delete a matter of this type.
  • Selecting can_restrict allows users assigned to this role to restrict matters of this type. When a matter is restricted, only the person who enabled the restriction can access the matter. They can also nominate other users who will be able to access it. Users with full admin permission cannot see a restricted matter unless the user who set that restriction allows them to. 




Working with Division-Based Permissions

Many permissions include additional options for controlling user access either by division or by the user's role within a matter. For example, a role within your firm might have permission to view (or can_read) all matters from all the divisions but can only delete matters in the division their user was created in.

NOTE:  Most Actionstep systems use only a single division. If this applies to your firm or system, leave this option set to either the default (Division, Sub or Peer Divisions) or just Division. To learn more about divisions, see What is a Division

You can access your list of divisions by going to Admin > Divisions.


All divisions are given a hierarchy.


A sub-division is a division that is under the current division, like this:


In the above example, if a login is under the Jones Lawgroup division and it has permissions set for Division or Sub-Divisions, then that login can see matters under all divisions. If a login is under Edward Jones Law and there are no additional sub-divisions, it will only have permission to view Edward Jones Law.


A peer division is a division on the same level as your division under the same head division.

In this scenario, a user with a login to Summit Gold Coast will also be able to see matters under Summit Sydney because it is a peer division. That user cannot see Summit Law Partners, however, because it is a division above. If there were divisions listed below, they would not have access to those either, since they would be subdivisions. 


If you choose the Specific Divisions option when assigning the permission, you can choose which divisions this system role can access. You can select more than one division by pressing Ctrl (Windows) or Command (Mac) while clicking each division. 




Restricting Access Based on Matters

You can choose to limit system role access to matters depending on if users assigned to that role are involved in the matter. There are three options: 

  • The Matter is assigned to the user
  • Is any Participant Type
  • Is a specific Participant Type (which adds the option to choose one or more participant types)


Using these options, you could assign permissions so that a user will only see matters that they are either assigned to or a part of. Or, you could permission matters where the user has a particular role in a matter. For example, they can see matters where they are the attorney but not matters where they are the client.




Assigning Multiple Permission Options 

You can combine permissions and rules by clicking OR. For example, by setting up multiple conditional permissions, you can allow someone to view all matters in one division but only view matters in another division when those matters are assigned to that user. 




Granting Access to a New Matter Type and its Data Collections

By default, if you create a new matter type, non-admin users will not be able to see or access this matter type or any matters related to it. 


To grant these users access, you will need to set permissions for the different levels of access you want the role to have. This also means you need to set permissions for any custom data collections associated with the matter type. 

NOTE:  In the System Object list, data collections are prefixed by the text Data Collection [Matter Type Name]. There may be more than one data collection for a matter type so make sure you update permissions for each one.




List Views: Export and Print Permissions


You can allow system roles access to export and print from custom lists. 


To do this, select the System Role, and then select System Object Table from the System Object drop-down list.







Was this article helpful?

That’s Great!

Thank you for your feedback

Sorry! We couldn't be helpful

Thank you for your feedback

Let us know how can we improve this article!

Select at least one of the reasons
CAPTCHA verification is required.

Feedback sent

We appreciate your effort and will try to fix the article