We have a workflow that wants to assign a task to a group default member. Formerly, it assigned the task to all group members, and now we have the requirement to send to only one person. (I felt uncomfortable just putting someone's name in a role, even if the role was called "Last Person to Approve", because I believe over time the persongroup is going to more useful -- eventually "Use for Site" and "Use for Org" will be exploited properly.)
I retained my original persongroup "X", and now by convention the group default will be "The Person" for these assignments. Happily if the person needs to change, we add to the group and check the "Group Default" box. Okay, so still good design.
Where I am unhappy with the solution is the traversal in the task to reach this individual. Part of me feels like it should be driven by the workflow, but maybe my brain got tired and I couldn't find a neat, elegant way to traverse the workflow back to the persongroup assigned to this.
What I ended up doing was creating a relationship on the workorder to persongroupteam:
WO2PGT = [persongroup = 'X' AND groupdefault = 1]
and it feels wrong because this is basically a constant. Every workorder can see this persongroup now.
I redefined an existing role, so a simple role to persongroup "X" is now:
dataset/workorder/[:WO2PGT.RESPPARTY_PERSONS.personid]
which feels data-driven but somehow wrong, because of that janky relationship I built.
I suspect I could "get at" that persongroup another way, but ideally I'd like to have that persongroup specified in the workflow (and therefore workflow-specific and workflow-defined) and then traverse THAT to get to the group default of that PG.
Did I lose everyone on this? Am I over-optimizing?
Note, things I won't consider are automation scripts, new custom classes, etc. Those would be out of bounds for this, especially since I can roll a solution OOB.
------------------------------
-C
------------------------------
#AssetandFacilitiesManagement#Maximo