Setup > Users > Row-level permissions 

The management of roles is used to define in object management, the data filters in a very selective fashion as a function or the user concerned. It is particularly useful for filtering the data to be presented to users when connected via the Web interface or other external connections. For example, it is used during order entry to only display the orders passed by a specific customer or ordered by this customer (which in this case is the user).

This management is based on :

*    definition of the role codes (customer, payer, representative, supplier...), which can be freely carried out in a miscellaneous table (table number 60)

*    the association, for the objects for which a filter is to be established, of a field in the principal table with the role code. It is this association that will be used to establish the data filter criterion. The roles management documented here is used to define these associations.

*    in an operational fashion in the user record, the assignment of one or more roles with the corresponding codes (a maximum of 30). It is this assignment that will define the automatic filters in the object management concerned.


Once these parameters are defined and the roles (and the corresponding codes) have been defined in the user record :

*    A filter is created in the object (left list, selection window) using the code(s) defined in the user record.

*    A control is made during the creation of the filtered fields.

*    A filter can be carried out in the requester.

Warning, the filters have the following limitations :

*    The left list filtering is only made in the fields of the principal table in the object (no filtering in the picking either)

*    In the case where the entry of a key is prohibited without passing by a selection, the entry is accepted initially, the control being carried out at the end.

In the case where several roles are defined in the user record, the rule is the following :

*    if the roles are identical and the associated key is different, an or logic is made between the conditions.

*    if the roles are different, an and logic is made between the conditions.


In the next section are several examples to illustrate this logic : Imagine the following filter :

*    the products by buyer code (BUY field associated with the object ITM for the buyer role)

*    the purchase orders by supplier (BPSNUM field associated with the POH for the supplier)

*    the purchase orders also by buyer code (BUY field associated with the POH for the buyer role)

If the user JOHNDOE possesses the buyer role for the codes MARTIN and DURAND, and the supplier role for the codes DUPONT, DUPUIS, and DUMONT, the filters will be as follows :

*    In supplier order entry, only the orders passed to the suppliers DUPONT, DUPUIS, or DUMONT, and involving the buyers MARTIN or DURAND will be available.

*     If an order created, the selection window for the buyers and suppliers will correctly filter the authorised buyers and orders. On the other hand, if a prohibited code is entered, it will only be controlled when an attempt is made to confirm the order.

*    The products ordered will also be filtered on-line at the time of their selection as a function of the buyers. Even here, if a product that is not bought by one of the buyers is entered, the checks will only be made at the time of confirming the order.

*    On the other hand, no filter on the display of an order for the product (if the supplier orders have been passed on products normally filtered for the user it is possible to select them, their modification will be refused).


The technical implementation is made by the automatic addition of the filters to the table managed by the object management. These filters are both active in the standard selection and in the left list. Below is a more technical example. If the following associations are defined for the customer role (defined for example with the code BPC), and the commercial role (defined for example with the code REP) :

*    in the object SIH (customer invoice), the BPC role introduces a filter on the BPR field (invoiced BP code).

*    in the object SOH (customer order), the role BPC introduces a filter on the field BPCORD (sold-to customer).

*    in the object BPC (customer), the role BPC introduces a filter on the BPCNUM filed (customer code).

*    in the object SOH(customer order), the role REP, introduces a filter on the REP field (sales representative).

If a user possesses the role BPC in its record associated with the code MARTIN, a filter on the object SIH will automatically be carried out : (BPR="MARTIN"), on the object SOH (BPCORD="MARTIN"), and on the object BPC (BPCNUM="MARTIN").

Of course, only the filters corresponding to a role associated with the user are active. This, if the user does not have the role BPC in its record, the filters defined above will not be carried out : the user will get all the orders, all the invoices and all the customer (provided no other filters - by group of sites, by other roles - have not been defined for the user).

The following illustrates the composition of several filters :

*    if the user has the role BPC three times with the customers MARTIN, DURAND, and DUPUIS, the filter on the customer record will be :

*    if the user has the role BPC associated with the code MARTIN, and the role REP associated with the code DUPUIS, the filter carried out on the order management will be :

A final important point : a mass filter on the data in a table where the left list is not strictly sorted according to the filter criteria can be very heavily penalised in terms of the response time. It is therefore advisable to use optimisation indexes and declare them in the left list.

Finally, it is important to note that the filter introduced by the roles is not managed by the standard reports (this will be impossible due to the possible extremes of the parameterisation), nor by the standards enquiries. It is therefore necessary to create specific reports if they should be made accessible to external users (but this is possible by playing with the access codes in order to dedicate reports specifically filtered for these users).


SEEREFERTTO Refer to documentation Implementation

Screen management

Entry screen


The definition of the roles is made in a global entry in the grid. The following triplet of information is defined in this grid :

*    the object code on which the filter is made (the name of the object is displayed)

*    the role code for which a filter is carried out(the role title is displayed)

*    the field on which the filtering is carried out. This field can only be a field in the principal table linked to the object, a link to the linked tables is not possible.




The following fields are present on this tab :


The role allowing control of the access to several functions (objects).

It is possible to attach to a single role several objects. For example, a role for the modification of a customer item can be defined and it can be considered that the object BIC entered for an invoice and an object SOH entered for a customer order are not accessible except for certain customers.

For each object, it is necessary to define a field in which the control will be made. In the examples above, the fields BPR business partners and BPCORD customer order have been defined.

The authorisation access have been defined in the user management.

The roles are listed in the miscellaneous table 60.


  • Field (field FLD)




Other conditions

It is possible to carryout controls on the roles in real time on certain specific/custom fields and this is done in a very simple fashion, by using the CROLE action as the control action. This is not carried out as standard because its use on all the fields would provoke numerous exchanges between the client and the server, where as in general this type of control is carried out on very few fields.

Menu Bar

This button is used to copy the role in another folder accessible from the server where the current folder is located.

Error messages

In addition to the generic error messages, the following messages can appear during the entry :

Basic objects : XXX key non existent

A non existent object has been entered.

Miscellaneous tables : XXX key non existent

A non existent role has been entered.

Non-existent field

A field has been entered that does not exist in the principal table associated with the object.

Tables used

SEEREFERTTO Refer to documentation Implementation