Introducing public preview of AppGroups – for sharing responsibility for client applications

[Marsh]

Launching today is a new way to model the relationship between a group of client applications and the people who share responsibility for those apps. AppGroups is now available in Public Preview for all Apigee X customers. (AppGroups will become available to hybrid customers in the upcoming 1.10.0 release.)

Logically, an AppGroup represents an entity that collects together multiple client applications that are managed by the same set of people. Multiple stakeholders often work as a team to share access to the set of apps represented by an AppGroup. When combined with a developer portal team concept, multiple people can now collectively manage their different applications at the same time. This not only streamlines processes around managing multiple apps, but it supports healthy team collaboration and delegation of responsibilities. 

To enable this from the portal side, we are accompanying this release with an update to the Apigee's Teams module for Drupal. In addition to using the new resource, the module introduces new settings:

1. An optional channelId attribute that can be used to identify which portal instance is responsible for the associated Team. This can help administrators distinguish between apps that were created from internal vs external portals or from pre-production vs production portals.  
2. An optional prefix used in the resource's machine name. When combined with conditional IAM rules in GCP, this can be used to restrict access to apps created from specific portals. 
3. A new attribute called channelUri to support journeys between the runtime-oriented entity view and the associated team in a developer portal. 

If you are familiar with the developer-apps entities in Apigee, AppGroups should already look familiar, as it shares many of the same concepts. Both AppGroups and AppGroup-apps support custom attributes properties, and at launch, the limits for AppGroups' apps are similar to developer-apps (though we plan to increase those on the path to general availability). Note that today AppGroups is exposed only as an API, admin UI is planned for the future release. Support for Monetization and for integrated portals will also be considered for future releases. 

To learn more, read the new documentation that describes how to use AppGroups to organize apps in more detail.

[ElangoD]

This a great feature for team to collab, thanks for sharing 

[dchiesa1]

Whoo-hoo!  I'm very much looking forward to helping customers adopt this new capability, Marsh! 

[jaredk]

Hello, for Integrated Portal users, does this provide any additional functionality that isn't already provided by Teams? Maybe I'm misunderstanding the purpose behind AppGroups, but it seems like I can already do the same things with Teams (although not via an API). Teams definitely has its downsides (happy to provide feedback on that here if desired), but I'm not sure how AppGroups differ.