Fusion organization/governance ideas

[JohnJOSullivan]

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.

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. 

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)

[Doug_Den_Hoed__AtAppStore]

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

[lgaertner]

Hello John, Hello Doug, Hello Community,

I just wanted to create a new thread to ask around for some tips concerning "organization within Fusion", when I saw this thread.

We need some ways so have a better overview over our Fusion scenarios. As it is not possible to create subfolders, we are only able to put specific scenarios into a corresponding folder, but are not able to divide by topic.

So far, we have only created a single team, as the administration of Fusion is carried out exclusively by our IT team.

Now I had the idea to use the teams as the "root layer" and the folders within the teams for "topics".

Would that make sense, or are there any stumbling blocks that might make us regret restructuring?

I am looking forward to hear your thoughts and possible doubts...

Besides that, I created some helpful Python scripts, which talk to the Fusion API to backup scenarios, webhooks, connections and data structures. The next step will be to put them into a Gitlab.

Another idea that has been on my mind for some time is, to program a Python script, which "converts" a Fusion blueprint into an UML diagram for documentation. I'm often a bit annoyed by the fact that you can't see the most important parameters of a module at a glance and that clicking on and displaying this information sometimes takes 10 - 15 seconds.

Regards

[Kelly_StarzEnt]

Hi,

Do you have a link to the documentation to the Fusion API?
I'm interested in building some Python scripts as well.

thanks,

Kelly

[lgaertner]

Hello Kelly,

As Fusion is originally based on make.com (formerly known as Integromat), you can use this documentation:

https://www.make.com/en/api-documentation

Not everything is working, as Fusion is sometimes a bit limited, but I had no problems to write a backup script as mentioned above.

Regards

Lars