Auto-Provisioning and Group Syncing for Multiple Applications in Appian

You can enable auto-provisioning through SAML or LDAP sync in Admin Console. For application separation, create prefixed groups (APP1_Users, APP2_Users) and map external identity provider groups to these groups during sync. Apply security at the application level using these dedicated groups, ensuring users only access their authorized applications. This provides automated user management while maintaining strict application boundaries.

For more detailed information, you can check out existing community discussion
https://community.appian.com/discussions/f/administration/18470/auto-provisioning-a-user-with-saml-when-an-authentication-group-is-specified-in-saml-idp

Need a little clarity on the difference in attributes that we will associate with Custom Group Types and Groups? Are both same?

What I understand is if we have an assertion claim from the IdP/ Entra ID like:

<Attribute Name="memberOf">
  <AttributeValue>Appian-Finance</AttributeValue>
  <AttributeValue>Appian-HR</AttributeValue>
</Attribute>

We have created the Custom Group Type with values:

• Group Type Name: External Synced Group
• Attribute Field: externalGroupId 

And created 2 Groups:

• Group1: Finance Team

  • Group Type: External Synced Group
  • Group Attribute (externalGroupId): Appian-Finance
    

• Group2: HR Team

  • Group Type: External Synced Group
  • Group Attribute (externalGroupId): Appian-HR


Are Appian-Finance and Appian-HR are the Entra ID group names?

Custom Group Types are used to add extra metadata fields (like externalGroupId) to groups. Groups are the actual security objects that get assigned these types and field values. For SAML/Entra ID integration, values like "Appian-Finance" and "Appian-HR" in the SAML assertion should exactly match the externalGroupId of your Appian groups.
This allows users to be auto-assigned to the correct Appian groups based on their Entra ID group membership. So, Custom Group Types define structure, Groups use that structure, and the attribute values must match what’s sent from Entra ID for syncing to work.

https://docs.appian.com/suite/help/25.2/Group_Management.html

Custom Group Types are used to add extra metadata fields (like externalGroupId) to groups. Groups are the actual security objects that get assigned these types and field values. For SAML/Entra ID integration, values like "Appian-Finance" and "Appian-HR" in the SAML assertion should exactly match the externalGroupId of your Appian groups.
This allows users to be auto-assigned to the correct Appian groups based on their Entra ID group membership. So, Custom Group Types define structure, Groups use that structure, and the attribute values must match what’s sent from Entra ID for syncing to work.

https://docs.appian.com/suite/help/25.2/Group_Management.html

Is it recommended to use different group types for different applications in Appian?
According to the 'Group Membership Synchronization' section in Appian’s SAML SSO documentation(SAML for Single Sign-On - Appian 25.2), only groups of a single group type are synchronized per identity provider. So, if we create two group types for two different applications, would that require setting up two separate IdP connections?

Additionally, the 'Identity Provider Ordering' section mentions that when multiple IdPs are configured, users should not belong to more than one authentication group. If a user does belong to multiple authentication groups, the order of IdPs determines which one is used.

This raises a concern: if a user needs different levels of access in two separate applications, each with its own group type and priority, how would that work in practice?

No, you should not use different group types per application if using the same IdP in Appian - only one group type can be synced per IdP connection. If you create multiple group types, you’ll need a separate IdP for each, which adds complexity.

The best practice is to use a single group type and create application-specific groups within it for flexible access.