• State Suggested Answer
  • Replies replies
    8
  • Answers answer
    1
  • Subscribers subscribers
    17
  • Views views
    515
  • Users 0 members are here

Workflow Examples of using a Group Approver

Jimbot
 

Does anyone have an example of using a IG Group as an approver in a approval step in a workflow?   We are trying to use Entity.get with a group, and it always fails to evaluate, or it returns null.  Not sure if we are using it correctly.   There are several examples of using Entity.get to return the supervisor of a user:

Entity.get('user', recipient, 'supervisor')

Has anyone seen or used Entity.get to return a group type object, or rather, all its members to assign to a approval.   We are using the Group Approval type, since that supports multiple DNs.

Entity.get('group', '49', 'members')    <-  I'm getting a group object, its groupId is 49 in IG, and I want the members list back, to assign each as the assignee.

However, this fails.   I've tried a number of things. Am I using the wrong groupID (should it be uniqueGroupId?)   

The docs on this are a little vague, I'd love to see an example if there is one floating about.

-Jim 

Parents

  • Suggested Answer

    0  

    For us the following call worked to get a multi-value attribute from a user (attributename = ext_ipgIGReviews). We also got the supervisor back (don't know why)

    JSON.stringify(Entity.getObject('user', flowdata.get('review/userId'), ['ext_ipgIGReviews'])) ->

    We used this call in a log activity. So, we had to use "Entity.getObject" and put the attribute in " [ ] "

    BR

    Tobias

    EDIT:
    For information only. The response is then an array and has a JSON entry.
    If you only want the JSON, an "(Entity.getObject('user', flowdata.get('review/userId'), ['ext_ipgIGReviews'])[0]" was enough for us

  • 0   in reply to   

    Hrm, I still can't for the life of me assign an IG group as an approver in Group Approval mode or normal. I've tried the group ID's, I've tried using the Entity.getObject call (which I can confirm returns stuff), and thrown it into JSON.  

    --Jim

  • 0   in reply to   

    Ahhhhhhhhh, I've realized that when you assign a group as an assignee on a approval activity, it uses the group ID from source as the 'full name' of the approver, and the db column to store that is only 32 chars, so if you group id is too big, it fails.   When I shrink my group id's, its all good! Slight smile

  • 0   in reply to   

    That is a very interesting problem. At what point do you shrink the group ID, is it directly when importing the group in a transformation script or can you do it in the workflow?

    Good to hear that the problem has been solved!

Reply Children
  • 0   in reply to   

    I shrink the group ID during Identity collection.  I was using the DN of the group coming from eDiras the Group ID from Source, but I changed it to the cn.  In my case all my "IG Groups" are in the same eDir container, so I know they are unique.  In a larger deployment spread across multiple containers, that might be a problem since cn's could be duplicated.

    If you tried to fix it in the workflow, it would be too late.  The workflow need to store the Group ID from Source in the task table, and it can't if it's too long.  So, for now, the only workaround that I can think of is to change the Group as you pull it in via the identity collection.

    --Jim

Resources

Support
Documentation
Learning Services
Partner Programs
Privacy
Compliance
Help
Company
Privacy Policy
Terms of Use
Cookies Preferences
Accessibility
Anti-Slavery Statement
Support
Contact Us
Careers
Code of Business Conduct and Ethics
The opinions expressed above are the personal opinions of the authors, not of OpenText. By using this site, you accept the Terms of Use. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.), Hewlett Packard Enterprise Company, or Micro Focus. As of January 31, 2023, the Material is now offered by OpenText, a separately owned and operated company. Any reference to the HP, Hewlett Packard Enterprise/HPE, and Micro Focus marks is historical in nature and the HP, Hewlett Packard Enterprise/HPE, and Micro Focus marks are the property of their respective owners.