Hi Everyone, I am stucked with one of the most important use case of

Hi Everyone,

I am stucked with one of the most important use case of my application. My objective is that users latest present in users array process variable must only see the process information which I am posting on tempo. If any user is added from that array then along with the previous users , those newly added users must also see the info on tempo now. And if any user(s) are removed, then those removed users(s) should no longer be able to access or see the info of that process instance on tempo.On whole, users present latest in that user array process variable must only see the info on tempo and no one else.

In order to do, I created one parent group('X') of my application. Now, whenever a new instance of process is spawned, using Identity Management Smart service, I create a subgroup('X1') of that Parent Group('X') and then add or remove users in this subgroup('X1') accordingly and then pass 'X1' to the viewers group of Post feed to tempo sma...

OriginalPostID-62228

OriginalPostID-62228

  Discussion posts and replies are publicly visible

  • ...rt service.
    This works fine for me and my required functionality works fine, However when I go through the Best Practices of Creating Custom Groups,somewhere it states, that one should avoid creating too many custom groups until and unless required to a greater extent. So, By following the above stated approach, my use case works fine, but it will create number of custom groups equal to the number of instances spawned by the process, ie, groups created are directly proportional to the number of instances spawned.In my application, I am expecting around 10 instances to be created daily.

    Therefore in order to achieve my use case, is there any other way around keeping in mind all the best practices.
    Looking forward for your valuable suggestions,

    Thanks in advance
    Siddharth.
  • I also have to create a lot of groups as I need very tight access permissions for many processes and the permitted users are determined in process flow. I had a talk to Appian PS about this and they said that groups and groupmembership are cheap in Appian. If there is no other solution to the problem, groups are not a problem in general as long as you do housekeeping and delete them asap.

    Do you have any numbers? Are we talking of 100, 1000, 10000 of groups and process instances?
  • @shelzle: Hi shelzle! Thanks for the update. Yes, I am expecting around 500 instances to be spawned every month for my process, which counts to around 6000 instances in an year or so.

    So, in that case we don't have any other option , other than to create custom groups for each instance to implement security and above mentioned use case??Any by doing so, we won't be violating any best practices of Appian?
  • How long are these processe running? Try to archive them and delete the group asap.

    Best practices are meant to make you think about what you are doing. In case you are not able to adhere to a best practice think about the what you can do to prevent getting into trouble. Worst case: your processes are running for years and groups will never be deleted.

    If you are not shure about your design, try to get help from professional services.
  • @Shelzle: My use case says that the instances will be there for about 12 months(1 year). Yes, you are correct. There can be a separate scheduled process that will delete the groups after desired time as specified using delete team smart service.
    Thanks for the help.