"System Objects" are names associated with various parts of the Actionstep system to allow you to set permissions on them. New system objects are created for each action type and data collection that you create.

Opening the System Object Permission Editor

System Object Permissions are controlled through the System Object Security Editor. You can find the System Object Security Editor under the System Role screen (Administration > Permissions > System Roles).

Using the System Object Permission Editor

There are a number of different parts of Actionstep and you can use the System Object Permission Editor to decide what people can do within the many different functions of Actionstep. These functions are broken down into a number of different options which we call System Objects. 

There are a number of System Objects and all are self explanatory so we won't go into detail but it is important to know that as well as System Objects to cover basic functions (eg, deleting documents, viewing emails) there is a system Object created for each Action Type that you create and a System Object for each Data Collection within an Action Type. 

Navigating

Depending on what you are wanting to change you can use the drop down option at the top of the System Object Security Editor or use the buttons at the bottom. 

If you are wanting to update or review all the System Object Permissions for a System Role it is worthwhile using the Prev and Next arrow buttons at the bottom of the screen.

Permission Options

There are some System Object Permissions which are specific (eg, the ability to overwrite a rate sheet that is used in a time sheet) but most give simple options to allow a user to either read, create, edit or delete certain things.

To give basic permissions use the tick boxes to the left hand side of the description of the permission. There are no secrets here. If you tick the box then the system role can do what it says beside the box.  

In the screenshot below the System Role ("Accounts & HR") can read the "1. General Action" action type and can modify it. They cannot create this action type and they cannot delete any matter that has previously been created from this Action Type.

Read - They can view actions/matters of this type in any lists or views that would display them and they can search for and open any matter of this type in the top right hand search box.

Create - When creating a new action/matter they can see this Action Type as one of the options they can choose.

Modify - They can make changes to a action/matter once opened.

Delete - They can delete a action/matter of this type.

Restrict - They can restrict a matter of this type. Restricting will mean that that user, the one who is restricting the matter, is the only person on the system who can access that matter. That user can nominate other users who will be able to access it. Users with full administration permission cannot see a restricted matter unless the user who set that restriction allows them to. 

Most databases will just use these options but further restrictions can be placed. Under each option is the choice to control the system users access by division or by the users role within an action/matter.

In the examples below I will assume that you are working on permission to read an action or matter but the same logic applies to any of the other options as well. For example, someone might have permission to view all matters from all the divisions but only be able to delete matters from the division their login is  made under.

Divisions that a action/matter is assigned to

By default it is set to "Division" but you also have the option to choose "Division or Sub-Divisions", "Division or Peer Divisions", Division, Sub or Peer Divisions" or "Specific Divisions".

All divisions are given a hierarchy. A sub-division is a division that is under the current division. So if you had a database that had three divisions setup like below:

If a login is under the HQ division and it has permission for "Division or Sub-Divisions" then it can see matters under all divisions. If a login is under Beijing then there are no sub-divisions under this so it will only have permission to Beijing.

A Peer Division is a division on the same level as your division under the same head division. Using the scenario above, a user with a login to New York will be able to also see matters under Beijing because it is a peer division but not HQ because it is a division above and not Boston because it is a sub-division.

Choosing Specific Divisions will give you the option to choose which divisions this System Role can access. Another drop down list will appear listing all the databases divisions. You can select more than one division by holding down the ctrl key while clicking on divisions. 

Participant of Actions/matters

You can choose to limit a System Roles access to actions or matters depending on if they are involved or not. There are three options: "The Action is assigned to the user", "is any Participant Type" or "is a specific Participant Type...".

These do as they say. You can choose so that someone only sees matters that they are assigned to, or matters that they are part of. Or where they are 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.

Multiple options

You can combine rules as well be clicking the green plus symbol to create an Or situation. This way you can have someone who has access to read matters in Division 1 but can only read matters from division 2 when those matters are assigned to that person. 

Common permissions you might need to set

Access to a new Action or Matter Type

If you create a new matter type then users will not be able to see this matter type until you have updated the system object permission for this matter type and to the custom data collections within that matter type.

To grant your system users access to a new matter type choose the option: "Action Type <<New Matter Types Name>> (id=<<MatterTypeNumber>>)".

In the example below the Matter types name is: "1. General Action".

Once you update the permission for one system role click save then use the System Role drop down menu to choose another system role and update the permission for that.

You will also have to update the permissions for the custom data collections on the matter. Using the System Object drop down menu choose the system object with the name: "Data Collection [<<Matter Type Name>>] ::<<Custom Data Collection Name>> (id=<<DataCollectionNumber>>)".

In the example below the Matter Types name is: "1. General Action"

The Data Collection's name is: "checklist"

List Views: Export and Print Permissions

To grant rights to export and print from custom lists edit the "System Object Table" permissions.

Related Articles:

- System Role Permissions

- Menu Permissions