Hi, Everyone I am trying to incorporate security on feeds that are b

...e mentioned objective, I also want that for each instance spawned for my process, a separate group is created under one Parent group and that group will contain the list of users latest present in pv!users and those only will be able to see the feeds that are been posted on tempo.

Thanks In Advance,
Siddharth.

Hi Siddharth, togroup(pv!users) does not create a dynamic group -- togroup() is meant to convert groupID to an Appian Group. More so, you cannot control security of a Tempo Event by using just a process variable (pv!users).

Having said so, you seem to be on the right track based on your last approach. You can certainly create a Custom Group per workflow (instance of the main process). You can then user Add and Remove Group Members Smart Services to control the group membership.

Note the caveat:
1) User must logout from the Tempo Web UI for the Group Membership changes to take into effect, or system will automatically update his/her Group Membership if the user is idle for 20 minutes (system default for Group Membership cache update).
2) If the users are using mobile interface #1 comment still applies.

Please let me know if you have questions.

Questions: Using this approach, how many groups you think you will end up creating in the Production in a year? In other words, how many instances of the main process are you expecting per year?

Hi, if you have list of all user in pv!user variable then there is no need to use Viewer Group by using togroup, we can directly pass that varaible to User option in Data Tab... might this help

@Sushil I would caution against this approach. Note that the list of all users in a group is not the same as the group itself. It is a snapshot of that group's membership at the moment in time when the list of users was derived, and is therefore not guaranteed to represent that group's membership as users are subsequently added and/or removed.

@abhishek, Could you please let me know any other way to update the group membeship without logging out?

Currently, there is no way to programmatically update the Group Membership Cache without logging out or waiting for the idle time (20 mins) of the cache.

I understand that you may be finding it a bit challenging without an automatic way of updating this Cache, but if you consider the real world (in Production), it is generally not an issue. Such a pattern of changing group membership in Process works well in Production, as users eventually either logout or stay idle for 20 mins for his/her group membership changes to take effect. Especially with Tempo Event security, it will work just fine, unless you absolutely need the Events to show up real-time in the user's Tempo interface -- but think of the Production environment while designing your system, and not of the Development environment.

Please let me how what works the best for you, and we may be able to suggest something else. Hope this helps!

@abhishek Thanks a lot for your suggestions. I thought of creating a smart service which updates the group membership cache so that the user can se the post immediately without logging out. Since I am new to Appian I don't know whether this is feasible or not. So could you please provide some suggestions for the procedure i thought of or is there any other way to achieve this functionality?

@abhishek: I am expecting atleast 20 instances to be spawned for my process every day, which counts to approx 600 instances in each month and 7200 instances in an year, which I think is not a good option for doing so.

However the option which you have suggested was not working out.When I am creating a group (as a subgroup) for each instance spawned with Parent group as "Tempo Audience Group", then the group created is not inheriting the security from the Parent Group - "Tempo Audience Group", and hence irrespective of lists of those users who are present in the group, all the users are still able to access the respective feeds.

However if I dont create a group with parent group as "Tempo Audience Group", and simply pass the "Tempo Audience Group" in the Viewers group of Tempo smart service, then it works fine, but again it will create separate group at root for each instance spawned.That is, approx 7200 groups AT ROOT, for just my process, which is not at all a best practice.

Can you please throw some light on it??
Thanks.

@Sikhivahan As I already mentioned, it is not possible to refresh the Group Membership Cache in a SmartService plugin either.

@Siddharth I may have misinterpreted you group hierarchy, but I was explaining what you may do in-general. For your use case, you do not need to worry about "Tempo Audience Group" (TAG) what-so-ever. This group has a different purpose and is used ONLY for making the groups available in the Tempo UI (Message Tab) as target groups.

What I meant is to do the following: Create a Custom group (*NOT* as subgroup of TAG, but of some other predefined Custom group) -> Add members to this group -> Post to Tempo Event with this group as Viewers group. Now, by adding/removing users to/from this group, you can control the availability of the Tempo Event.

Having said so, please check your use case, do you really need so much control per Tempo Event? Consider -
1. Making the Tempo Event content better searchable, and train your users to use search if feasible,
2. Using predefined group hierarchy to control access/viewability instead of creating groups per instance. For instance, you can create N number of predefined groups, you may be able to target the posts based on certain rules, or you can do a combination of predefined and dynamic groups (if the predefined ones do not fit the rule criteria).

Would doing so work for you? Ideally, I would refrain from creating so many dynamic groups, just from the scalability point of view. But if you have no other choice (please explain in detail -- why?), and we can discuss approaches.

@abhishek: Thanks for the help.However, as I told you following this approach will create many groups in the environment wherein no of groups created will be directly proportional to the instances spawn for the process. Actually I have to show the tempo feeds related to that process only to those users which are latest present in the array of users at lastest time. Users can be updated anytime throughout the lifetime of the process, and only the lastest users should then see the tempo feeds. Hence, for doing so I need to create custom groups with parent group as predefined group and then adding and removing users from the subgroup.So if 100 instances are spawned in a day, 100 sub groups will be created.
Is there any work around where in groups are created once the process starts and are deleted dynamically as soon as it gets terminated?

Looking forward for your suggestions and help.

Thanks.