Hi Paul,

The MS example uses pre-defined labels and associated categories to define access, whereas this project uses ordinary filters without any reference to security. So administrators can write any filter specifying row level access, and users (or roles, actually) have access to the union of whatever filters they've been assigned. Such assignments are dynamic, in that adding/deleting filters/roles is automatically reflected in what each user sees. This made the model intuitive for administrators, and trivial to implement for legacy apps.

High volume transactions are irrelevant since security is only applied to a gateway table and users only update single records at a time on that table.