Defining Case Visibility for loggedinuser()

Please read my blog post. If I understand your use case correctly, this should be a good fit.

https://appian.rocks/2022/08/15/strict-security-with-synchronized-records/

Hi Stefan Helzle ,

In our scenario, user is not only the foreign key. User and CaseType are the foreign keys where the user will be a Group at the initial stage and any one person from the group can pick the task and progress on it. Can this be achieved using above approach?

I have a hard time following your description.

The basic idea, is to define permission on the access record, using security rules. Then, just have the case record inherit from the access record. If you can describe your requirements using security rules, it should just work.

On the interface, based on the logged-in user, pull data from the User Access Details table. Store this data in a local variable.
Loop through each row in the local variable and query the Cases data table for each row using queryFilter on product and platform. You might get multiple entries. Flattening the output using flatten().
You can display these entries as desired.

Added sample code for your understanding
Let me know if that works for you.

a!localVariables(
  local!userAccessDetails: /*Pull data from user access detail here(Multiple Entries for loggedIn User)*/
a!flatten(  a!forEach(
    items: local!userAccessDetails,
    expression: a!queryRecordType(
      recordType: {},
      filters: {
        a!queryFilter(
          field: "product",
          operator: "=",
          value: index(local!userAccessDetails, "product", {})
        ),
        a!queryFilter(
          field: "platform",
          operator: "=",
          value: index(local!userAccessDetails, "platform", {})
        )
      },
      
    )
  )
  )
)

Shubham Aware   We already tried this approach, but record is not accepting rule! functions

A query in a loop is not a good idea in terms of performance.

The problem here is we wont have the user always. It will be group when the case is created.
Attaching screenshot for reference

User access details

Data table

For A user, 1001 and 1003 will be visible and for B user, only 1003 should be visible(extended version of access details)

Since user is not populated initially, we cannot establish a direct relationship. Is there any other workaround for this?

For me, it looks like your data model does not really fit your requirements.

With security rules, you can easily permit access to a user based on username, or group membership. Why not add rows for each case to the access table where you store either a group or a user.

caseid | user | group

1001; A; some_group

Add these items based on the respective product and platform.

You mean something like below

1) A;some_group;123; pqr
2) A;some_group_123;xyz

3) A;some_group;456;pqr
 and so on??

Plus,Business doesnt want individual rows for all combinations
They want only individual entry for one group

Sorry, but I already described what I mean.

And, since when does business define how we implement a technical aspect, they will never see anyways.