Security Settings allow you to control which users can see which Records. Security Settings are broken up into 2 types- User / Team Security and Record Data Security.



User / Team Security

User / Team Security is fairly straight forward. If you want to keep users fropm seeing this Record Type, add them by user or team into the No Access section. Anyone in here will never see this Record Type or its Records. Even if you put them into another security setting, No Access trumps all.


If you want users to see Record but not edit them, put them into the Read Only area. Likewise, if they need to see and change the Records, put them into the Read / Write area. If a user is in both Read Ony and Read / Write then they will get the higher of the rights which would be Read / Write.


The one thing to keep in mind is the system-level Base Security setting in the Main Options. If the Base Security is set to Read / Write then ALL users will have Read/ Write to ALL Record Types unless they are specifically in one of the other No Access or Read Only areas. If the Base Security is set to Read Only then ALL users will have ReadOnly to ALL Record Types unless they are specifically in one of the other No Access or Read /Write areas. If the Base Security is set to No Access then ALL users will have NO ACCESS to ANY Record Types unless they are specifically in one of the other Read / Write or Read Only areas.



Record Data Security

Record Data Scurity is a bit more complex and is therefore a less efficient process so use it sparingly.The basics of this are simple. IF a user is defined in directly or by team in the rules then they are limited by extra criteria. For instance, if you want to be sure that users in the AP-Indexing team can only see records that are assigned to them (i.e. their User ID is in a fiel dnamed "AssignedTo")then you could set it up as in the following image.



This tells the system that anytime a user in the AP-Indexing teams searches this Record Type, add "AssignedTo" = '[USERID]" to the search so they only get records back that have their User ID in that field. You can add multiple criteria but, as always, the more you add the slower the system performs. Sometimes it is best to add a single field that holds a value based on 3 or 4 other fields and use that one field for security rather than have 3 or 4 fields in the security setting.





Multiple Possible Values

An advanced usage of this feature is to compare a field value with a list of possible matches. You can do this by setting the Value From setting to a list delimited by | (pipe) symbols. For instance, you could set a security rule where an invoice is only visible if the Department field is set to "HR", "Admin", "Warehouse" or "Other". Just set the Field Name to "Department" and Field Value to "HR|Admin|Warehouse|Other". 



Team Security

You can combine the Multiple Possible Values method above with the variable called USERTEAMS to secure a record based on team membership. [USERTEAMS()] will return a pipe-delimited list of all the team names in which the current user is a member. If you use this for the Field Value setting then if any of that user's team names match the field value then they will have access.



AND vs OR Logic

If a user matches more than one Record Security rule, then the rules are applied by default using OR logic. This means if a Record matches ANY of the rules then the user is allowed access. The opposite logic uses the Exclusive Rule setting which converts that rule to use AND logic. If the Exclusive switch is set and the user is affected by this rule then that rule MUST be matched in order to see the Record. 


As an example, if you have one rule that affects a user that says they can only see Records where Vendor=ACME (exclusive) and another that says they can only see where PAID=NO (exclusive) then the user can see all ACME records where PAID=NO. If both of the rules are NOT exclusive then the user will see all records where Vendor=ACME OR Paid=NO. Which means they may see Records from other vendors where PAID=NO and could also see PAID=Yes records for ACME.



Best Practice Use

The AND and OR logic can typically be used inside of a single rule. You can have one rule that says the user is limited to ACME and PAID. This is normally the preferred method. You should only add extra rules if you cannot embed all the logic into one rule. Also, try to minimize the number of rules that affect a single user or team. Not only is it more complicated to deal with but the more rules a user is affected by, the slower their searching will be.



** BE CAREFUL WITH RECORD SECURITY. Its complexity is not just apparent when defining it but also when it runs. Record Security places a much larger load on teh server than any other security setting. If a user is in 5 of these rules then that is 5 times more processing the system must do! If that user is configured similarly in 3 other Record Types and that user performs a Global Search then the system uses 15 times more processing (3 record types x 5 rules each) when it searches!!