Forum Discussion
I think I would prefer the separate Org option. The main burden is then manually moving things you want to share from one place to the other. Given that you are okay with moving things, I guess my next question would be if you foresee other departments requiring access and integration at a future point. If marketing is the only one then standing up one other org and switching from one to the other shouldn’t be too painful. However, you don’t want this to always be a n+1 problem and have org proliferation.
People also generally don’t like to touch things once in production and if in the same org, you would need to probably move your Snaplexes from org>shared to org>Production>shared so that marketing would not be able to run pipelines on the production Snaplex for the single-org model.
Those are my main thoughts. HTH!
-Tim
Thanks for the thought-out responses!
Or environment currently consists of 3 Orgs (Dev, QA, Prod)
We have 2 SnapPlexes (Cloud and Ground) that are at the Org-Shared level.
We have defined Project spaces to align with line-of-business development groups
Org
Ecommerce
Corporate Systems
Store Systems
etc…
Marketing is the first set of users that aren’t purely development groups but will not be the last. This needs to a be a practical and sustainable pattern going forward. Seeing as how Orgs cost money, it won’t be accepted very well for departments with one or two users.
The solution we’re leaning toward is to
A) create a new project space called Marketing
B) create a new SnapPlex called Marketing within the Marketing project space’s share.
We have 4 additional nodes pending installation. As far as I know, we should be able to assign one or more of those nodes to the Marketing SnapPlex to isolate the server resources to that group. The problem that remains is keeping the Marketing users from running their pipelines on the Cloud or Ground SnapPlexes. I see two option here. First, as Time mentioned, is to move the existing SnapPlexes down from the org share into a lower level. The problem is that we have many Project Spaces that would all need to have SnapPlexes made. The second option is to remove access from “all users” to the org shared folder. Instead, put every user in a group and grant that group access. Keep marketing left out in their own group that only has access to their Project space. We’d just need to move down common shared objects that we want the the Marketing group into their project space as well.
We do have an Integration Success Team in place to facilitate this sort of management within SnapLogic.
Side note: Seems a bit strange that a SnapPlex, which is merely a run-time environemnt, is shared along with other pipelines and accounts rather than their own type of entity that can have access granted outside of the project structure.
- shodge9 years agoFormer Employee
@tlui and I were talking about this the other day. We’re certainly open to suggestions to make the workflow more logical; FWIW, I’m with you on this one, but if we’re going to separate it out we want to make sure the redesign is actually a better user experience, so feedback is very welcome.
Shayne
- del9 years agoContributor III
@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.
- shodge9 years agoFormer Employee
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