This section walks through the series of tasks to implement a sample, role-based scenario: provide IDD users with four different privilege levels (no permissions, read-only, create, and update) to access a Party base object and affiliated resources.

For example, consider a scenario with two subject areas such as Party and Organization and the Party subject area has as a logical one-to-one relationship with the Organization subject area. In the data view, to edit any attributes of the record, you must have the CREATE and UPDATE privilege on both the subject areas that is C_PARTY and C_ORGANIZATION. If some fields in the primary object or the object with a logical one-to-one relationship with the primary object are READ-ONLY, you can still edit the primary object. The fields that are READ-ONLY are visible in Data view, but cannot be edited. If all the fields in the primary object and the object with a logical one-to-one relationship with the primary object have READ-ONLY permissions, you cannot edit the primary object in Data view.