Partner Portal With Row-Level Segregation

The URL parameter is client-controlled. A report filter that trusts it is a display convenience, not an authorization control. The pilot user changed the value and the report returned another partner's row because the server never checked whether that operator was entitled to that shipment.

The replacement should be server-side attribute-based access control (ABAC) on the Shipment Exception case type. Map the operator's partner organization to a case property, such as PartnerID, and create an access control policy that permits read or write only when the operator's partner attribute matches the case attribute. Apply the policy to the case type, reports, data pages, and case search so every path is covered, not just the original report.

Keep role-based access control for function: PartnerUser can read, and a separate PartnerEditor role or privilege can write the delivery window. Do not create 40 access groups just to segregate rows unless there is a separate operational reason; one partner access group plus ABAC is easier to maintain. Test with CanRead and CanWrite checks using operators from two different partners, and verify that report definitions and list views also enforce the policy. Division or organization structures are not a substitute for row-level policy here.

I would separate row-level access from property-level access.

Row-level: the ABAC policy restricts every partner user to shipments where the case PartnerID matches their own partner attribute. That applies to the three editors as well; write access does not grant cross-partner visibility.

Property-level:

• Driver phone and consignee address should be masked for partner users. Use property-level access control or a data masking pattern so the unmasked value is not sent to the browser. Do not mask only in the UI with a when rule; a user could still retrieve the value through another path.
• For the three editors, create a PartnerEditor role with write access to DeliveryWindow and read access to the rest of the partner-visible fields. Assign that role only to those users or to a separate access group. The other 37 partners keep PartnerUser with read-only access to DeliveryWindow.
• If the delivery window change needs approval, model it as a case-level change request rather than direct property edit.
• Encrypt sensitive properties at rest where required, and restrict who can see unmasked values internally.

The judgement call is least privilege by function and by row. ABAC handles the row; roles and property access handle the field and action.

I would enable auditing at two levels: case history for changes and access logging for sensitive reads.

Change auditing:

• Enable audit on the Shipment Exception case type and on the sensitive properties, including DeliveryWindow, driver phone, and consignee address. Capture operator ID, timestamp, old value, and new value.
• Ensure the audit record is written when the change is submitted, not only when the assignment is opened.
• Restrict access to audit history to internal audit and compliance roles, not partner users.

Read auditing:

• Case history alone will not prove who viewed PII. If the audit team requires read evidence, log access to the unmasked PII through the data page or service that retrieves it. Record operator ID, shipment ID, timestamp, and whether the value was masked.
• Do not log the unmasked PII itself in the access log; log the event and the record identifier.
• Review logs for abnormal patterns, such as a partner user accessing many shipments outside their normal volume.

Also test that ABAC denials are logged or at least observable, so attempted cross-partner access is visible. Retention should follow the company's audit policy. The key is to prove both authorized access and changes without turning the audit log into another PII store.