QBO security boils down to two concepts:
Functional security is maintained via Design > Security, and include build-in system functions such as:
Granting a user permission to select (view) a loan does not necessarily imply that they get to select any loan in the system; instead, they can only select those loans to which they have access via extranet security (see below).
Once functional security has been address, one should consider which rows of data a user may perform these functions on. For example, in a BPO system, BPO clients should typically have the right to search and select valuations, but they should be limited to search for and selecting only those valuations for which they are a client. BPO agents should be able to select (view) and update the data associated with a BPO (valuation update), but only for those BPOs which they are the agent for. Extranet security limits access to only those rows of data which the user has been granted access to.
Fortunately, granting access to a row of data is typically done automatically by the QBO system. For the examples above:
When a BofA user navigates to a BPO Search page, and searches for all BPOs, the system will check:
For many situations, users may well need to essentially view all rows in a system. The company that contracts directly with Quandis to create a QBO instance (Quandis' 'client') will typically have users that should be able to see all data, regardless of which client sent them the data, or which vendor may be fulfilling services related to the data. Such users should be members of a 'universal access' Role. Members of a universal access role bypass the extranet security model, but are still subject to the functional security role.