We have a requirement to see the cases on dashboard based on some criteria. This criteria is defined in a table called user access details. Details of all the cases are present in one record.
How can we apply these user access details values as filters inside another record to get the values??
Note: For a single user, there can be multiple user access details, so there will be multiple rows. Each row need to be applied as filter to the record.
Screenshots have been added for reference. First image refers to user access details, second one refers to data table
When User A logs into Appian, they should see only caseid 1001, when user B logs in they should see only case 1003. How can we achieve this using Records??
We already tried using record level security, but here we can define only static values. But, in our scenario we need to define dynamic values which will be varied on logged in user.
Discussion posts and replies are publicly visible
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.
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; pqr2) A;some_group_123;xyz
3) A;some_group;456;pqr and so on??Plus,Business doesnt want individual rows for all combinationsThey 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.
The issue is the user access data will be directly edited by business from the front end. So if we split data for each and every product, platform respectively, they will appear as individual rows in the front end. Once we split the data, and try to combine it once again, we might misinterpret the data. Thats why I said business is not ok with having individual rows
Why do you have to display individual rows then? You can have individual rows in the back end and have a single row on the interface level just to display. I agree with Stefan here, Business will not be aware how things can be or should be when it comes to implementation. Its in your hands to handle that and in the front end you give them what they want.I think your requirement is straight forward. You collect the data against each user and create multiple unique rows and when you display try displaying in a single row with the list of Products or Platforms related. I guess records should come in handy and also some mapping of data in the interface variables if needed.
Then, you will have to find a way to turn this into a usable UI. But trying to create a permission model on some "interesting" ideas from the business side will get you into trouble.