Shared-flows - between orgs and versioning?

[akashtp]

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?

[akashtp]

@Vinit Mehta Can you please share your valuable inputs here?

[#3]

Good questions - @evan.scheessele @Akash Prabhashankar

1) I understand that having SF/FH be available across Orgs is a very valid use case for some. However our current RBAC and modeling is around the notion of Org being the highest level of logical separation. Hence it totally made sense to add shared flows at the same level as API proxy aka..within an Org. Point taken and we will explore this option with our products team and evaluate accordingly.

However we now have a way to manage and deploy SF's through maven. Just like API Proxies, even SF can be moved around from one Org to another in a seamless manner keeping the same code base. Check it out here

2) Versioning in Shared Flows - IMHO it makes sense to have versions for something that has an endpoint and can be invoked stand alone. SF's does not have an endpoint and hence can not be invoked stand alone. I believe most of the use cases could be addressed by revisions. As mentioned one can always have a nomenclature to support the need to version.

This feature is here to evolve and enhance to meet all the customer use cases, so please keep the feedback coming.

Thanks!

[evan_scheessele]

Thanks @Vinit Mehta for your feedback. For #2, you mention most use-cases can work with revisions. Do you think revisions can work well for a core team providing shared-flows out to myriad API Teams in a multi-org enterprise environment? I don't want to disrupt the independent release-management and devops autonomy of the API Teams.