Flow Studio Structure
Folder Structure
The application folder structure in Flow Studio does not affect how users see the flows in clients. It is only there to keep some law and order for the designers. Try to set a standard that will keep it tidy from the get-go. It could be based on process and/or site (location), but it will probably vary between projects.
Try to maintain the same folder structure in the Dev, Test and Prod environments.
Maintain separate folders as follows.
Project Folder
It is always recommended to create a master folder for the main project/solution that you are working on. If there are sub solutions, create them as sub folders within the main structure. If the project/solution that you are working on targeted to be used as a template in the future, it is important to maintain the below folder structure within the main project folder.
Menus
We know from experience that it can be tricky to put menus in the correct folders. Because menus are so entangled with the security structure, sooner or later the structure tends to be confusing. To simplify things, put all menus in a separate folder called "Menus" in the structure root.
General Fragments
There can be fragments that would be reused by multiple flows making them general fragments. A good example for this would be a fragment built to get user defaults (Company, Site, Employee, etc) that can be used for all flows developed in a solution. Such fragments should be put in a separate folder called "General Fragments" in structure root or project folder.
Pro Tip:
When using subscribed workflows, create a simple parent user flow as a dummy flow and include the general fragments, and then use this dummy flow to subscribe on the production server. This will put the dummy parent flow—together with the fragments—where you put the dummy flow. The fragments would otherwise end up with the first flow you happen to subscribe to. This can be a little confusing on the subscription target server. Having a dummy parent also makes it easier to test your fragments without having to run a complex flow.
Solution Specific Fragments
In instances where you have fragments developed for a specific solution, it is recommended to keep those fragments in a separate folder called "Fragments" inside the respective project folder. This helps to maintain a similar structure when subscription is used in the subscribed environment.
Scheduled Workflows
When exporting an environment and importing it somewhere else, it might be important to turn workflows off. In later versions there will be a place to manage and supervise scheduled workflows. Until then, put scheduled workflows in a separate folder called "Scheduled Workflows" in structure root or project folder.
CRUD Workflows for Portal
When creating CRUD workflows for portlets in portal solution, put those CRUD workflows in a separate folder "CRUD Workflows" in structure root or project folder.
Last updated
