Announcements
This site is in read only until July 22 as we migrate to a new platform; refer to this community post for more details.
Get hands-on experience with 20+ free Google Cloud products and $300 in free credit for new customers.

Shared-flows - between orgs and versioning?

Two questions based on observed inadequacies:


Imagine a company ABC develops a Shared Flow called "ABC-API-Security"


1) Is there a POR to allow Shared Flows to work across orgs? If ABC more than 15 or 20 orgs, and wants to apply standard Shared Flows like "ABC-API-Security" for certain centralized governance requirements. Having to replicate the exact same Shared Flow across all the orgs feels unnecessary, redundant.

2) How about Shared Flows and versioning? I see the revisions options, much like proxies, but Shared Flows, being *shared* have special needs: I play a central role developing Shared Flows used by many different API Teams -- like the hypothetical "ABC-API-Security"... I want to release an improved version of the corporate standard "ABC-API-Security" Shared Flow, and ask the API teams to migrate to using the updated version on their independent schedules. I don't want to force the revision onto the API Teams' production APIs without their performing the release themselves. As the feature works today I can only publish a new revision to a non-production env and ask them all to test, ahead of my releasing the "ABC-API-Security" revision to production once their all confirm testing. This forces it into play, but by my own hand. Alternatively I could create a new Shared Flow with an updated name like "ABC-API-Security-v2.0" and ask the various API Teams to transition over to that on their own testing cycles, but it means I'm doing versioning within the naming convention, which is a little ugly. Will this space be evolving?

7 3 434
3 REPLIES 3