Citizen Integrator Solution?
Hello all,
We’re in the process of on-boarding our first Citizen Integrator in the SnapLogic Platform. We’ve previously federated the development of production integrations to LOB developers, but t...
Forum Discussion
@shodge, my feedback on this, without a lot of analysis to determine caveats, is to create an org-level configuration to host snaplexes (either instead of or in addition to project-level configuration). Then each project (or project space) could be configured to target any or all snaplexes at org level. Then permissions to certain org-level snaplexes (for user, pipeline, task, etc.) would be inherited from the project (or project space) permissions to related snaplexes.
use case: projA has access to snaplexA & snaplexB while projB has access to snaplexA & snaplexC and projMarketing only has access to snaplexMarketing.
Thanks for the feedback.
Am I correct that this doesn’t change the current permissions model / inheritance, it just moves the Snaplexes into their own (linked back to projects) UI area?
Thanks,
Shayne
@shodge, I think you mostly captured what I was saying. I think the paradigm shift is how we look at the globally shared project. I’ve reworked my thoughts and the use case a little bit below. I’m going to use accounts instead of snaplexes to better demonstrate the case, but it works similarly for snaplexes and shared pipelines.
Use Case:
- Workday is used for ERP - both HCM & Finance
- A minimum of 3 project spaces are utilized by IT to organize Workday-related integrations: HCM, Finance, and Service Management
- 4 Workday tenants are implemented: Production, Sandbox, Dev, and Sandbox Preview
- Workday-related pipelines may require (for each tenant) Workday accounts, SOAP WSSE accounts, and REST accounts. This results in a minimum of 9 accounts to maintain in the globally shared project to be shared across all Workday-related project spaces.
- The business is attempting to implement a citizen integrator strategy for LOB. But the the LOB integrators have no business accessing Workday HCM or Finance data without strict authorization governance…
Current options are:
- Remove the 9 accounts from the globally shared project and create and maintain them in each of the 3+ Workday-related project spaces (27+ accounts to maintain)
- Create new SnapLogic org(s) and snaplexes for the new citizen integrator team(s), resulting in potentially significant add to the budget.
- Nix the whole citizen integrator strategy
- Dynamic accounts might be useful in this case, but we don’t want to broadcast passwords out to everyone that has project read access
So, my platform enhancement suggestion might be to create a globally shared/restricted project space where access is not controlled by a user/group mapping, but by a project mapping. Everything else in the platform remains the same.
Thanks for the suggestion and use cases. We’ll discuss it internally with the UX team. It’s very helpful to have a concrete use case for these discussions, so thanks for including the additional details.
Shayne
