I am working with MHAriete64 on this same project and attempted to implement all of the above suggestions without achieving the results that we are aiming for. Regardless, I would like to offer much gratitude to bcooney and Mr. Vodka for the help thus far! I’ll re-iterate our problem in light of attempting the previous proposed solutions: First off, the solution in question requires a number of different User Accounts with several levels of Access and Privileges across multiple Entities. I’m calling any group or organization that wants to use this database as a template for its own sets of records an Entity. In essence, what we would really like to achieve would be to have one server-based database that can be used by several different Entities, each Entity containing multiple User Accounts with their own respective Privilege Sets. There would be a Main Entity hosting the base-level database and serving several sub-entities, each having their own User Accounts, respective sets of records while using the same general layouts/ fields. The Main Entity has “root” level access to all of the records of itself and the various sub-entities. The sub-entities can view and modify only their own sets of records and not even see the current 2000+ records in the Main Entities’ database. In other words, a sub-entity seeing 2000+ records with “” printed in 295 fields would not be an efficient way to browse its own additional 300+ records. This was the result of attempting to use the Get ( PrivilegeSetName ) = PrivSetCreated in the RLA view calculation. For sake of portability, this problem cannot easily be solved by using Get(AccountName) as the sentinel value for determining sets of records to be viewed based on Privilege Set for reasons that should now be apparent by the above description or our database schema. To further compound the problem there is another key variable at work here. There are a set of particular fields in each record that are populated with rather sensitive data via a scripting process that queries yet another server. It would be desirable that this scripting be run exclusively through the Main Entity for all records across all entities, thus the need for both the encapsulation of the sub-entities and root level access for the Main. I hope this helps shed some light on the complexity of our dilemma. Thanks in advance for any help and expertise you can offer. It is very much appreciated.