Expand my Community achievements bar.

Fusion organization/governance ideas

Avatar

Level 4

Hi all,

 

I'm thinking through how to use teams in Fusion--along with other governance-y stuff. I'm pretty sure what I want to do but want to float out my thoughts. 

 

The history of our instance of Fusion: We (Aetna) were the only users of Fusion till we brought in the other teams from CVS Health. Now that we're all in one place, I want to be sure that we have the right level of segmentation while allowing for use of shared scenarios. 

 

So, my thinking: We have some scenarios that Aetna developed which run a bunch of different automations based upon a common trigger. I'm calling those scenarios "General" scenarios. For those scenarios, I'm planning on moving them into a new team called "General Enterprise Scenarios." Scenarios that are "Company" specific exist within teams (e.g. CVS Retail, Aetna, Caremark, Bob's Burgers, etc.). Integrations with other systems exist within their own teams. 

 

Our governance structure for Workfront is relatively new but is now functional and working well. Fusion governance is still like a gleam in someone's eye before a margarita festival. But I have some pretty obvious things established:

 

* Any new work in Fusion needs to be brought to Fusion administration (me)

* Any use of new company/integration specific scenarios needs to be brought to Enterprise Administration and Enterprise Governance

* Adding new automations to general scenarios doesn't require Enterprise Admin approval, but does require Fusion admin (me) to review the automation and plug it into the appropriate general scenario. This ensures no one steps on any one else's toes. Plus it helps us learn from one another.

* To that end, there's also an accepted "gentleman's agreement" among all us Fusion users that we only work on our own things and don't touch anyone else's without permission.

 

I also want to extend the error handling scenario I built for everyone's automations. I have data store modules attached to Ignore error handlers at known chokepoints in scenarios. All that information ends up in a data store. The scenario reads the data store at 5 p.m., counts the errors, adds the information into a lookup project (for reporting purposes), collects all the info into a temp CSV, takes the info and stores it into an Excel spreadsheet, zaps the data store, and emails me to let me know how many times Fusion errored out. I used an Excel sheet because of data store limitations.

 

JohnJOSullivan_0-1687013060246.png

 

What I'm thinking of doing is retiring the data store (considering it only exists within the one team). I'm going to replace all the data store modules with Excel modules, have the info go right there, and have Fusion do all of the info gathering from the Excel sheet. 

 

excel.jpg

That's a little bit of a detour from my question. Just wanted to show that I know some stuff. I might actually do that work now even though it's a Saturday. I'm a sick man.

 

Anyhow, just wanted to air my thoughts and wondered if this sounded familiar to others. I should really get off of this thing on the weekend.

 

Thanks for your help!

 

-John J. O'Sullivan (CVS Health)

1 Reply

Avatar

Level 10

 

Happy Saturday @JohnJOSullivan, and nice timing.

 

Yesterday, I lead a spontaneous conversation with a half dozen or so Fusion whizzes in which we exchanged several similar ideas around best practices, rules of thumbs, gotchas, and hopes and dreams. While it's fresh in my mind -- and with a tip of the hat to those who contributed -- a few highlights to offer...

 

  • your Gentleman's Agreement is an excellent idea; certainly, look, learn, and copy, but dinna touch MY stuff, so I need not worry if it's unexpectedly changed
  • in a related story (just because you're paranoid doesn't mean they're not watching...), we kicked around the idea of using an external source code tool such as GitHub or TortoiseSVN for several reasons, including backup (of the JSON), documentation notes (since the native choices are limited), and the ability to use the (e.g. in TortoiseSVN, excellent) DIFF features to check for differences in order to learn (or in case Something Seems Strange, such as someone made a change without adding it to the repository, ahem, "educate")
  • having observed that -- similar to trying to look up and add an existing parameter to a custom form, etc. -- Fusion's developer UI performance will become slower as more data is added to an instance, in addition to taking steps to avoid that situation (i.e. keep your instance as tidy and light as possible), consider using generic approaches rather than those tied to Workfront since the former will then skip the (slow) loading steps, making it more productive (and pleasant) to navigate and work
  • for documentations (both advanced and basic), make.com has some excellent (highly compatible) resources and a thriving developer community

 

And finally, we mused: wouldn't it be amazing if Fusion's training, best practices, and resources could evolve into an obvious path for all to walk together (noting that what you're doing, what we did, and this conversation we're now having are all steps in the right direction...).

 

Regards,

Doug