Group Membership Workflow

This section provides information about functions, conditions, and variables for the group membership workflow, as well as initial actions and reserved actions.

Table of Contents

  1. Group Membership Workflow: Initial Actions
  2. Group Membership Workflow: Reserved Actions
  3. Group Membership Workflow: Functions
  4. Group Membership Workflow: Conditions
  5. Group Membership Workflow: Variable Resolvers

Group Membership Workflow: Initial Actions

The initial actions valid for Akana API Platform workflows relating to group membership are:

@Invite

Starts the workflow for a new group member. Used to control workflow actions that occur when a member is invited to a group.

This is the default initial action, used in most cases.

@Import

Starts the workflow when group membership information is imported. Takes the group membership direct to the Approved state.

Back to top

Group Membership Workflow: Reserved Actions

The following reserved actions are defined for group membership workflows:

@RecreateInPendingState

Used to control workflow actions that occur when a group membership action is recreated in pending state.

@RecreateInAcceptedState

Used to control workflow actions that occur when a group membership action is recreated in accepted state.

@RecreateInDeclinedState

Used to control workflow actions that occur when a group membership action is recreated in declined state.

Group.membership.action.accept

Used to control workflow actions that occur when a group membership invitation is accepted.

group.membership.action.decline

Used to control workflow actions that occur when a group membership invitation is declined.

group.membership.action.resend

Used to control workflow actions that occur when a group membership invitation is resent.

group.membership.action.remove

Used to control workflow actions that occur when a group member is removed from the group.

group.membership.action.make.admin

Used to control workflow actions that occur when a group member who was a member or leader is made a group admin.

group.membership.action.make.leader

Used to control workflow actions that occur when a group member who was a member or admin is made a group leader.

group.membership.action.make.member

Used to control workflow actions that occur when a group member who was a member or leader is made a group member.

group.membership.action.group.deleted

Used to control workflow actions that occur when a group is deleted.

Back to top

Group Membership Workflow: Functions

The following functions are available for the group membership workflow:

setGroupMembershipRequestState

Changes the state of a group membership request to a new state specified in the parameter.

Parameters
Name Description/Values
State

The state that the group membership request is being set to. Valid values:

  • com.soa.group.membership.state.approved
  • com.soa.group.membership.state.disapproved
  • com.soa.group.membership.state.pending
  • com.soa.group.membership.state.removed
  • com.soa.group.membership.state.group.deleted
Examples/Notes/Additional Information

The example below shows the workflow step when an invited group member declines the invitation. As a result, the group membership request state is set to com.soa.group.membership.state.disapproved.

<action id="102" name="group.membership.action.decline">
  <restrict-to>
    <conditions type="AND">
      <condition type="isSelfMembership"></condition>
    </conditions>
  </restrict-to>
  <results>
    <unconditional-result old-status="Pending" status="Declined" step="300" />
  </results>
  <!--  update status to declined -->
  <post-functions>
    <function type="setGroupMembershipRequestState">
      <arg name="state">com.soa.group.membership.state.disapproved</arg>
    </function>
    <function type="sendGroupMembershipNotification">
      <arg name="notificationType">com.soa.notification.type.appteam.membership.rejected</arg>
      <arg name="groupType">com.soa.group.type.appteam</arg>
      <arg name="roles">role.group.all.members</arg>
    </function>
    <function type="sendGroupMembershipNotification">
      <arg name="notificationType">com.soa.notification.type.privateapi.membership.rejected</arg>
      <arg name="groupType">com.soa.group.type.private.apigroup</arg>
      <arg name="roles">role.group.all.members</arg>
    </function>
    <function type="sendGroupMembershipNotification">
      <arg name="notificationType">com.soa.notification.type.apiadmin.membership.rejected</arg>
      <arg name="groupType">com.soa.group.type.api.admingroup</arg>
      <arg name="roles">role.group.all.members</arg>
    </function>
    <function type="sendGroupMembershipNotification">
      <arg name="notificationType">com.soa.notification.type.bizadmin.membership.rejected</arg>
      <arg name="groupType">com.soa.group.type.business.admingroup</arg>
      <arg name="roles">role.group.all.members</arg>
    </function>
    <function type="sendGroupMembershipNotification">
      <arg name="notificationType">com.soa.notification.type.siteadmin.membership.rejected</arg>
      <arg name="groupType">com.soa.group.type.tenant.admingroup</arg>
      <arg name="roles">role.group.all.members</arg>
    </function>
    <function type="sendGroupMembershipNotification">
      <arg name="notificationType">com.soa.notification.type.group.membership.rejected</arg>
      <arg name="groupType">com.soa.group.type.independent</arg>
      <arg name="roles">role.group.all.members</arg>
    </function>
  </post-functions>
</action>

setGroupMembershipRole

Sets the group membership role for the specified group member to a new role.

Parameters
Name Description/Values
role

The group role which is now assigned to the specified group member. Valid values:

  • com.soa.group.membership.role.admin
  • com.soa.group.membership.role.leader
  • com.soa.group.membership.role.member
Examples/Notes/Additional Information

In the example below, the group member is made into a leader. The setGroupMembershipRole function is used to change the user's role to com.soa.group.membership.role.leader.

<action id="106" name="group.membership.action.make.leader">
  <restrict-to>
    <conditions type="OR">
      <condition type="isCallerGroupAdmin" />
      <condition type="isCallerSiteAdmin"/>
      <conditions type="AND">
<condition type="isCallerGroupLeader" />
<conditions type="OR">
  <condition type="isLeaderMembership" />
  <condition type="isMemberMembership" />
         </conditions>
      </conditions>
    </conditions>
  </restrict-to>
  <results>

    <unconditional-result old-status="Pending" status="Pending" step="100" />
  </results>
  <post-functions>
    <function type="setGroupMembershipRole">
      <arg name="role">com.soa.group.membership.role.leader</arg>
    </function>
    <function type="sendGroupMembershipNotification">
      <arg name="notificationType">com.soa.notification.type.privateapi.membership.status.changed</arg>
      <arg name="groupType">com.soa.group.type.private.apigroup</arg>
      <arg name="roles">role.group.all.members,role.invited.user</arg>
      <arg name="param.groupmembership.oldrole">${groupmembership.oldrole}</arg>
      <arg name="param.groupmembership.role">${groupmembership.role}</arg>
    </function>
    <function type="sendGroupMembershipNotification">
      <arg name="notificationType">com.soa.notification.type.group.membership.role.changed</arg>
      <arg name="groupType">com.soa.group.type.independent</arg>
      <arg name="roles">role.group.all.members,role.invited.user</arg>
      <arg name="param.groupmembership.oldrole">${groupmembership.oldrole}</arg>
      <arg name="param.groupmembership.role">${groupmembership.role}</arg>
    </function>
  </post-functions>
</action>

sendGroupMembershipNotification

Sends group membership email and dashboard notifications when parameters match the group membership. Since the same function is used for all groups and all membership, this function is designed so that different notifications can be sent to different roles or different group membership depending on the event.

Parameters
Name Description/Values
notificationType

Valid notification ID of the notification message template for the notification to be sent. For example:

  • com.soa.notification.type.appteam.member.invited.team
  • com.soa.notification.type.independent.group.deleted
groupType

Checks whether the sendGroupMembershipNotification function is for the current group type for which the membership is being updated. When the value of this parameter matches the group type of the group membership that is being affected, a notification is sent. Otherwise, no action is taken.

The group workflow is designed to accommodate several different group types. Depending on the group type, a different notification might be sent. This parameter tests the current group type.

Valid values:

  • com.soa.group.type.appteam: App team
  • com.soa.group.type.private.apigroup: Private API group
  • com.soa.group.type.tenant.admingroup: Site Administrator
  • com.soa.group.type.api.admingroup: API Administrator
  • com.soa.group.type.independent: Independent group
  • com.soa.group.type.business.admingroup: Business Administrator
Roles

Defines the roles to which the notification is sent, as a comma-separated list of role names.

Role names used for this parameter are:

  • role.group.all.members: the notification is sent to all confirmed members of the specified group or groups (admins, leaders, and members).
  • role.group.leader: Notification is sent to all leaders of the group.
  • role.group.admin: Notification is sent to all admins of the group.
  • role.group.member: Notification is sent to all members of the group.
  • role.invited.user.unregistered: Notification is sent to users who were invited but have not yet accepted the invitation (only if user is not yet registered on the platform).
  • role.invited.user.registered: Notification is sent to users who were invited but have not yet accepted the invitation (only if user is registered on the platform).
  • role.invited.user: Notification is sent to users who were invited but have not yet accepted the invitation (whether registered or unregistered).
  • role.inviting.user: Notification is sent to the user that is sending the invitation (applies to only invite and resend actions).
Any parameter with name prefixed with "param"

Parameter values for parameters with names starting with "param." Can be used in the notification template data.

Examples:

  • param.groupmembership.oldrole: Optional, used when a group member has a role change, to indicate the old role.
  • param.groupmembership.role: Optional, used when a group member has a role change, to indicate the new role.
Examples/Notes/Additional Information

The example below shows workflow steps when a group is deleted. One of two possible notifications is sent out, depending on the group type, to notify group members that the group was deleted.

<action id="108" name="group.membership.action.group.deleted">
  <results>
    <unconditional-result old-status="Pending" status="Group Deleted" step="400" />
  </results>
  <post-functions>
    <function type="setGroupMembershipRequestState">
      <arg name="state">com.soa.group.membership.state.group.deleted</arg>
    </function>
    <function type="sendGroupMembershipNotification">
      <arg name="notificationType">com.soa.notification.type.independent.group.deleted</arg>
      <arg name="groupType">com.soa.group.type.independent</arg>
      <arg name="roles">role.invited.user</arg>
    </function>
    <function type="sendGroupMembershipNotification">
      <arg name="notificationType">com.soa.notification.type.privateapi.group.deleted</arg>
      <arg name="groupType">com.soa.group.type.private.apigroup</arg>
      <arg name="roles">role.invited.user</arg>
    </function>
  </post-functions>
</action>

Back to top

Group Membership Workflow: Conditions

The following conditions apply to the group membership workflow:

isSelfMembership

Checks whether the group membership is for the logged-in user; returns Boolean true if so.

Arguments

None.

Examples/Notes/Additional Information

The example below shows workflow for when a group member accepts an invitation to join the group. Since the invited person is the only one who is authorized to accept the invitation, the workflow uses the isSelfMembership condition to check that the individual performing the action is the invited member.

<actions>
  <action id="101" name="group.membership.action.accept">
    <restrict-to>
      <conditions type="AND">
        <condition type="isSelfMembership"></condition>
      </conditions>
    </restrict-to>
    <results>
      <unconditional-result old-status="Pending" status="Accepted" step="200" />
    </results>
    <!--  update status to approved -->
    <post-functions>
      <function type="setGroupMembershipRequestState">
        <arg name="state">com.soa.group.membership.state.approved</arg>
      </function>
      <!--
      <function type="addBoardComment">
        <arg name="notificationType">com.soa.notification.type.accept.appteam.invite</arg>
      </function>
      -->
      <function type="sendGroupMembershipNotification">
        <arg name="notificationType">com.soa.notification.type.appteam.membership.accepted</arg>
        <arg name="groupType">com.soa.group.type.appteam</arg>
        <arg name="roles">role.group.all.members</arg>
      </function>
      <function type="sendGroupMembershipNotification">
        <arg name="notificationType">com.soa.notification.type.privateapi.membership.accepted</arg>
        <arg name="groupType">com.soa.group.type.private.apigroup</arg>
        <arg name="roles">role.group.all.members</arg>
      </function>
      <function type="sendGroupMembershipNotification">
        <arg name="notificationType">com.soa.notification.type.apiadmin.membership.accepted</arg>
        <arg name="groupType">com.soa.group.type.api.admingroup</arg>
        <arg name="roles">role.group.all.members</arg>
      </function>
      <function type="sendGroupMembershipNotification">
        <arg name="notificationType">com.soa.notification.type.bizadmin.membership.accepted</arg>
        <arg name="groupType">com.soa.group.type.business.admingroup</arg>
        <arg name="roles">role.group.all.members</arg>
      </function>
      <function type="sendGroupMembershipNotification">
        <arg name="notificationType">com.soa.notification.type.siteadmin.membership.accepted</arg>
        <arg name="groupType">com.soa.group.type.tenant.admingroup</arg>
        <arg name="roles">role.group.all.members</arg>
      </function>
      <function type="sendGroupMembershipNotification">
        <arg name="notificationType">com.soa.notification.type.group.membership.accepted</arg>
        <arg name="groupType">com.soa.group.type.independent</arg>
        <arg name="roles">role.group.all.members</arg>
      </function>
    </post-functions>
  </action>

isCallerSiteAdmin

Checks whether the logged-in user is a Site Admin; returns Boolean true if so.

Arguments

None.

Examples/Notes/Additional Information

In the example below, the action being performed changes a group member's role to admin. The conditions section tests that the user performing the action is either a group admin or a site admin, since these are the two roles authorized to perform the action.

<action id="105" name="group.membership.action.make.admin">
  <restrict-to>
    <conditions type="OR">
      <condition type="isCallerGroupAdmin" />
      <condition type="isCallerSiteAdmin"/>
    </conditions>
  </restrict-to>
  <results>
    <unconditional-result old-status="Pending" status="Pending" step="100" />
  </results>
  <post-functions>
    <function type="setGroupMembershipRole">
      <arg name="role">com.soa.group.membership.role.admin</arg>
    </function>
    <function type="sendGroupMembershipNotification">
      <arg name="notificationType">com.soa.notification.type.privateapi.membership.status.changed</arg>
      <arg name="groupType">com.soa.group.type.private.apigroup</arg>
      <arg name="roles">role.group.all.members,role.invited.user</arg>
      <arg name="param.groupmembership.oldrole">${groupmembership.oldrole}</arg>
      <arg name="param.groupmembership.role">${groupmembership.role}</arg>
    </function>
<function type="sendGroupMembershipNotification">
      <arg name="notificationType">com.soa.notification.type.group.membership.role.changed</arg>
      <arg name="groupType">com.soa.group.type.independent</arg>
      <arg name="roles">role.group.all.members,role.invited.user</arg>
      <arg name="param.groupmembership.oldrole">${groupmembership.oldrole}</arg>
      <arg name="param.groupmembership.role">${groupmembership.role}</arg>
    </function>
  </post-functions>
</action>

isCallerGroupAdmin

Checks whether the individual performing the action is an admin for the group; returns Boolean true if so.

Arguments

None.

Examples/Notes/Additional Information

In the example below, the action being performed changes a group member's role to admin. The conditions section tests that the user performing the action is either a group admin or a site admin, since these are the two roles authorized to perform the action.

<action id="105" name="group.membership.action.make.admin">
  <restrict-to>
    <conditions type="OR">
      <condition type="isCallerGroupAdmin" />
      <condition type="isCallerSiteAdmin"/>
    </conditions>
  </restrict-to>
  <results>
    <unconditional-result old-status="Pending" status="Pending" step="100" />
  </results>
  <post-functions>
    <function type="setGroupMembershipRole">
      <arg name="role">com.soa.group.membership.role.admin</arg>
    </function>
    <function type="sendGroupMembershipNotification">
      <arg name="notificationType">com.soa.notification.type.privateapi.membership.status.changed</arg>
      <arg name="groupType">com.soa.group.type.private.apigroup</arg>
      <arg name="roles">role.group.all.members,role.invited.user</arg>
      <arg name="param.groupmembership.oldrole">${groupmembership.oldrole}</arg>
      <arg name="param.groupmembership.role">${groupmembership.role}</arg>
    </function>
<function type="sendGroupMembershipNotification">
      <arg name="notificationType">com.soa.notification.type.group.membership.role.changed</arg>
      <arg name="groupType">com.soa.group.type.independent</arg>
      <arg name="roles">role.group.all.members,role.invited.user</arg>
      <arg name="param.groupmembership.oldrole">${groupmembership.oldrole}</arg>
      <arg name="param.groupmembership.role">${groupmembership.role}</arg>
    </function>
  </post-functions>
</action>

isCallerGroupAdminMember

Checks whether the logged-in user (the user triggering the action) is a group admin member; returns Boolean true if so.

Arguments

None.

isCallerGroupLeader

Checks whether the logged-in user is a group leader; returns Boolean true if so.

Arguments

None.

Examples/Notes/Additional Information

In the example below, the action being performed makes someone a group member. The conditions section specifies that a user who is a group admin or site admin can perform the action; additionally, a user who is a group leader can perform the action on another user who is a leader or member.

This limits the action to authorized individuals.

<action id="107" name="group.membership.action.make.member">
  <restrict-to>
    <conditions type="OR">
      <condition type="isCallerGroupAdmin" />
      <condition type="isCallerSiteAdmin"/>
      <conditions type="AND">
<condition type="isCallerGroupLeader" />
<conditions type="OR">
  <condition type="isLeaderMembership" />
  <condition type="isMemberMembership" />
         </conditions>
      </conditions>
    </conditions>
  </restrict-to>
  <results>
    <unconditional-result old-status="Pending" status="Pending" step="100" />
  </results>
  <post-functions>
    <function type="setGroupMembershipRole">
      <arg name="role">com.soa.group.membership.role.member</arg>
    </function>
    <function type="sendGroupMembershipNotification">
      <arg name="notificationType">com.soa.notification.type.privateapi.membership.status.changed</arg>
      <arg name="groupType">com.soa.group.type.private.apigroup</arg>
      <arg name="roles">role.group.all.members,role.invited.user</arg>
      <arg name="param.groupmembership.oldrole">${groupmembership.oldrole}</arg>
      <arg name="param.groupmembership.role">${groupmembership.role}</arg>
    </function>
    <function type="sendGroupMembershipNotification">
      <arg name="notificationType">com.soa.notification.type.group.membership.role.changed</arg>
      <arg name="groupType">com.soa.group.type.independent</arg>
      <arg name="roles">role.group.all.members,role.invited.user</arg>
      <arg name="param.groupmembership.oldrole">${groupmembership.oldrole}</arg>
      <arg name="param.groupmembership.role">${groupmembership.role}</arg>
    </function>
  </post-functions>
</action>

isCallerGroupMember

Checks whether the logged-in user is a group member; returns Boolean true if so.

Arguments

None.

isMemberMembership

Checks the role of the group membership being managed with the workflow to see if the role is Member (group membership represents member membership). If the role is Member, returns true.

Used in combination with isCallerGroupAdminMember, isCallerGroupLeader, and isCallerGroupMember:

To check the role of the user calling the workflow:

  • isCallerGroupAdminMember
  • isCallerSiteAdmin
  • isCallerGroupAdmin
  • isCallerGroupLeader
  • isCallerGroupMember

To check the role of the group membership being managed with the action:

  • isAdminMembership
  • isLeaderMembership
  • isMemberMembership
  • isSelfMembership

This combination of conditions verifies that the person calling the workflow has adequate rights to perform the action. A group admin can perform actions relating to admins, leaders, or members; a leader can perform actions relating to leaders or members; a member can perform actions relating to members.

Arguments

None.

Examples/Notes/Additional Information

In the example below, the action being performed is to assign an existing group member the role of member (as distinct from leader or admin). The "restrict-to" section tests that the user performing the action is either a group admin or a site admin, or that the user is a group leader and the action is being performed on a group member who has the role of leader or member; and, therefore, that the user performing the action is authorized to do so.

<action id="107" name="group.membership.action.make.member">
  <restrict-to>
    <conditions type="OR">
      <condition type="isCallerGroupAdmin" />
      <condition type="isCallerSiteAdmin"/>
      <conditions type="AND">
<condition type="isCallerGroupLeader" />
<conditions type="OR">
  <condition type="isLeaderMembership" />
  <condition type="isMemberMembership" />
         </conditions>
      </conditions>
    </conditions>
  </restrict-to>
  <results>
    <unconditional-result old-status="Pending" status="Pending" step="100" />
  </results>
  <post-functions>
    <function type="setGroupMembershipRole">
      <arg name="role">com.soa.group.membership.role.member</arg>
    </function>
    <function type="sendGroupMembershipNotification">
      <arg name="notificationType">com.soa.notification.type.privateapi.membership.status.changed</arg>
      <arg name="groupType">com.soa.group.type.private.apigroup</arg>
      <arg name="roles">role.group.all.members,role.invited.user</arg>
      <arg name="param.groupmembership.oldrole">${groupmembership.oldrole}</arg>
      <arg name="param.groupmembership.role">${groupmembership.role}</arg>
    </function>
    <function type="sendGroupMembershipNotification">

      <arg name="notificationType">com.soa.notification.type.group.membership.role.changed</arg>
      <arg name="groupType">com.soa.group.type.independent</arg>
      <arg name="roles">role.group.all.members,role.invited.user</arg>
      <arg name="param.groupmembership.oldrole">${groupmembership.oldrole}</arg>
      <arg name="param.groupmembership.role">${groupmembership.role}</arg>
    </function>
  </post-functions>
</action>

isLeaderMembership

Checks the role of the group membership being managed with the workflow to see if the role is Leader. If the role is Leader, returns true.

Used in combination with isCallerGroupAdminMember, isCallerGroupLeader, and isCallerGroupMember:

To check the role of the user calling the workflow:

  • isCallerGroupAdminMember
  • isCallerGroupLeader
  • isCallerGroupMember

To check the role of the group member being managed with the action:

  • isAdminMembership
  • isLeaderMembership
  • isMemberMembership

This combination of conditions verifies that the person calling the workflow has adequate rights to perform the action. A group admin can perform actions relating to admins, leaders, or members; a leader can perform actions relating to leaders or members; a member can perform actions relating to members.

Arguments

None.

Examples/Notes/Additional Information

In the example below, the action being performed is to assign an existing group member the role of leader (as distinct from member or admin). The "restrict-to" section tests that the user performing the action is either a group admin or a site admin, or that the user is a group leader and the action is being performed on a group member who has the role of leader or member; and, therefore, that the user performing the action is authorized to do so.

<action id="106" name="group.membership.action.make.leader">
  <restrict-to>
    <conditions type="OR">
      <condition type="isCallerGroupAdmin" />
      <condition type="isCallerSiteAdmin"/>
      <conditions type="AND">
<condition type="isCallerGroupLeader" />
<conditions type="OR">
  <condition type="isLeaderMembership" />
  <condition type="isMemberMembership" />
         </conditions>
      </conditions>
    </conditions>
  </restrict-to>
  <results>
    <unconditional-result old-status="Pending" status="Pending" step="100" />
  </results>
  <post-functions>
    <function type="setGroupMembershipRole">
      <arg name="role">com.soa.group.membership.role.leader</arg>
    </function>
    <function type="sendGroupMembershipNotification">
      <arg name="notificationType">com.soa.notification.type.privateapi.membership.status.changed</arg>
      <arg name="groupType">com.soa.group.type.private.apigroup</arg>
      <arg name="roles">role.group.all.members,role.invited.user</arg>
      <arg name="param.groupmembership.oldrole">${groupmembership.oldrole}</arg>
      <arg name="param.groupmembership.role">${groupmembership.role}</arg>
    </function>
    <function type="sendGroupMembershipNotification">
      <arg name="notificationType">com.soa.notification.type.group.membership.role.changed</arg>
      <arg name="groupType">com.soa.group.type.independent</arg>
      <arg name="roles">role.group.all.members,role.invited.user</arg>
      <arg name="param.groupmembership.oldrole">${groupmembership.oldrole}</arg>
      <arg name="param.groupmembership.role">${groupmembership.role}</arg>
    </function>
  </post-functions>
</action>

isAdminMembership

Checks the role of the group membership being managed with the workflow to see if the role is Admin. If the role is Admin, returns true.

Used in combination with isCallerGroupAdminMember, isCallerGroupLeader, and isCallerGroupMember:

To check the role of the user calling the workflow:

  • isCallerGroupAdminMember
  • isCallerGroupLeader
  • isCallerGroupMember

To check the role of the group member being managed with the action:

  • isAdminMembership
  • isLeaderMembership
  • isMemberMembership

This combination of conditions verifies that the person calling the workflow has adequate rights to perform the action. A group admin can perform actions relating to admins, leaders, or members; a leader can perform actions relating to leaders or members; a member can perform actions relating to members.

Arguments

None.

authorizeInviteeByDomain

Checks the domain of the invitee to make sure the domain is one of the domains specified as valid. If so, returns true. If the condition is not met, the invitation is not allowed.

This can be used as a security measure to help prevent user error in potentially inviting someone who should not be invited. For example, invitations can be limited to one specific domain for security purposes.

Arguments
Name Description/Values
domain

One or more domains that authorization is restricted to.

To include multiple values, you can either include multiple <domain> arguments or list multiple domains on one line, separated by commas.

Note: the value for this parameter should be the domain name used in Policy Manager for the applicable identity system. For Policy Manager, use Local Domain as the value.

Examples/Notes/Additional Information

In the example below, this condition specifies that only users on the platform's domain, acmepaymentscorp, can be invited.

<condition type="authorizeInviteeByDomain">
  <arg name="domain">acmepaymentscorp</arg>
</condition>

authorizeInviteeByDomainType

Checks the domain type of the invitee to make sure it is one of the domain types specified as valid. If so, returns true. If the condition is not met, the invitation is not allowed.

This can be used as a security measure to help prevent user error in potentially inviting someone who should not be invited. For example, invitations can be limited to one type of domain, such as LDAP, for security purposes.

Arguments
Name Description/Values
DomainType

One or more domain types (Identity System type in Policy Manager, Domain Type in the developer portal), that the action is restricted to.

To include multiple values, you can either include multiple <DomainType> arguments or list multiple domain types on one line, separated by commas.

Valid values:

  • Directory Server (domain type for LDAP)
  • CA SiteMinder (domain type for a CA SiteMinder domain)
  • com.soa.securitydomain.pingfederate.provider (PingFederate domain)
  • com.soa.securitydomain.fb.connector (Facebook Connector domain)
  • com.soa.securitydomain.openidconnect.relyingparty (OpenID Connect Relying Party domain)
  • com.soa.securitydomain.oauth.provider (OAuth Provider domain; not an identity store domain, but supports OAuth/OpenID for other domain users)
  • com.soa.securitydomain.google.connector (Google Connector domain)
  • SAML Web Browser SSO (SAML Web SSO SP domain)
Examples/Notes/Additional Information

The example below tests that the domain type is Directory Server. This limits invitees to LDAP users.

<condition type="authorizeInviteeByDomainType">
  <arg name="DomainType">Directory Server</arg>
</condition>

authorizeInviteeByEmail

Checks the email address of the invitee to make sure it matches the email address patterns specified in the argument. If so, returns true. If the condition is not met, the invitation is not allowed.

This can be used as a security measure to help prevent user error in potentially inviting someone who should not be invited. For example, invitations can be limited to one specific email domain for security purposes.

Arguments
Name Description/Values
email

One or more specific email address patterns valid for invitations.

To include multiple values, you can either include multiple <email> arguments or list multiple email values on one line, separated by commas.

Examples/Notes/Additional Information

The example below shows the general structure of this argument.

<condition type="authorizeInviteeByEmail">
  <arg name="email">Email Address,Pattern</arg>
</condition>

The two examples below show different approaches to restricting email address to two domains.

Example 1: Both domains on the same line, with comma separators, using the AND condition:

<restrict-to>
  <conditions type="AND">
    <condition type="authorizeByEmail">
      <arg name="email">.*@soa.com,.*@akana.com</arg>
    </condition>
  </conditions>
</restrict-to>

Example 2: Each domain on a separate line, using the OR condition:

<restrict-to>
  <conditions type="OR">
    <condition type="authorizeByEmail">
      <arg name="email">.*@soa.com</arg>
    </condition>
    <condition type="authorizeByEmail">
      <arg name="email">.*@akana.com</arg>
    </condition>
  </conditions>
</restrict-to>

authorizeInviteeByGroupName

Checks to make sure the invitee is a member of one of the specified groups. If so, returns true. If the condition is not met, the invitation is not allowed.

This can be used as a security measure to help prevent user error in potentially inviting someone who should not be invited. For example, invitations can be limited to one specific group for security purposes.

Note: If no domain argument is passed, the condition is applied to a platform group.

Arguments
Name Description/Values
domain

Optional: one or more domains that authorization is restricted to.

Only needed if the group is not a group on the developer portal; for example, a Policy Manager group. Defaults to developer portal groups.

To include multiple values, you can either include multiple <domain> arguments or list multiple domains on one line, separated by commas.

Note: the value for this parameter should be the domain name used in Policy Manager for the applicable identity system. For Policy Manager groups, use Local Domain as the value.

group

One or more groups that authorization is restricted to. By default, if the <domain> argument is not present, a group name is interpreted to mean a platform group.

To include multiple values, you can either include multiple <group> arguments or list multiple groups on one line, separated by commas.

Examples/Notes/Additional Information

In the example below, this condition specifies that in order to be invited, users must meet any one of the following sets of conditions:

  • Be a member of one of these two developer portal groups: CM_Group1 or CM_Group2
  • Be a member of one of these two Policy Manager groups on the local domain: PM_Group1 or PM_Group2
  • Be a member of one of these two groups on the LDAP domain: LDAP_Group1 or LDAP_Group2
<restrict-to>
  <conditions type="OR">
    <condition type="authorizeInviteeByGroupName">
      <arg name="group">CM_Group1, CM_Group2</arg>
    </condition>
    <condition type="authorizeInviteeByGroupName">
      <arg name="domain">Local Domain</arg>
      <arg name="group">PM_Group1,PM_Group2</arg>
    </condition>
            <condition type="authorizeInviteeByGroupName">
      <arg name="domain">ldap</arg>
      <arg name="group">LDAP_Group1,LDAP_Group2</arg>
    </condition>
  </conditions>
</restrict-to>

Back to top

Group Membership Workflow: Variable Resolvers

The following variables are available for the group membership workflow:

${group.dn}

The unique GroupID for the group.

${group.type}

A value indicating the group type as a string in the format ${group.type}.

Valid values:

  • com.soa.group.type.tenant.admingroup
  • com.soa.group.type.business.admingroup
  • com.soa.group.type.internal
  • com.soa.group.type.appteam
  • com.soa.group.type.api.admingroup
  • com.soa.group.type.independent
  • com.soa.group.type.private.apigroup

${group.membership.request.dn}

The unique GroupMembershipRequestID. This is the Board Item ID corresponding to the group membership request. All audits related to the group membership are tracked under this request ID.

${membership.id}

The unique ID for the individual's membership in the group; a number.

${member.dn}

The unique User ID of the group member.

${groupmembership.oldrole}

The previous group membership role.

When the setGroupMembershipRole function is used, this variable is set with old role name of the group membership for use in subsequent conditions and functions.

${groupmembership.oldstate}

The previous group membership state.

When the setGroupMembershipRequestState function is used, this variable is set with the state name of the group membership for use in subsequent conditions and functions for the duration of the workflow action being performed.

${groupmembership.role}

The group membership role.

${groupmembership.state}

The group membership state.

Back to top