Flow designer Migration capability ??

jayprx
Tera Contributor

Guys,

 

I want to migrate existing Schedule jobs, Business rules,  Workflows , Script Includes what would be the best strategy and how it would be beneficial for future scope ??

 

how to decide when we need to use server side script br or flow designer for feature scope ??

 

Please repose thank;

1 ACCEPTED SOLUTION

Ethan Davies
Mega Sage
Mega Sage

Your general principle should be 'Flow First'. If you are building anything scheduled, asynchronous, or workflow-related then you should aim to build it in Flow Designer first. If you need to build a custom function in a Flow then you can create Flow Action to do so (or call a script include if the code already exists). There is almost nothing you won't be able to do using Flow Designer. It will cater for the simple to the complex. Of course, there are some limitations, but you likely won't encounter them for the areas you listed above. For things like schedules and catalog items, Flow is a no-brainer. In terms of Business Rules, I would say there isn't much value in converting what you have to Flows unless it can be asynchronous, and can be easily / quickly built into a Flow, if it works now and it is not causing performance issues it will be fine, Business Rules are not going away anytime soon.

 

For existing configurations, some of the decision factors in migrating to Flow Designer should be:

  • Will this future-proof my functionality? Is what we are using now still supported? Is it going to be deprecated soon?
  • Will this enable me to use native functionality to replace code/custom functionality I have written?
  • Will it make my functionality easier to maintain? Will it allow non-technical people to be involved in the process?
  • Will it be time-consuming / expensive to migrate what we have built-in without Flow Designer?

P.S. Script Includes are not included in this, they serve a unique purpose that cannot be replaced with Flows.

View solution in original post

1 REPLY 1

Ethan Davies
Mega Sage
Mega Sage

Your general principle should be 'Flow First'. If you are building anything scheduled, asynchronous, or workflow-related then you should aim to build it in Flow Designer first. If you need to build a custom function in a Flow then you can create Flow Action to do so (or call a script include if the code already exists). There is almost nothing you won't be able to do using Flow Designer. It will cater for the simple to the complex. Of course, there are some limitations, but you likely won't encounter them for the areas you listed above. For things like schedules and catalog items, Flow is a no-brainer. In terms of Business Rules, I would say there isn't much value in converting what you have to Flows unless it can be asynchronous, and can be easily / quickly built into a Flow, if it works now and it is not causing performance issues it will be fine, Business Rules are not going away anytime soon.

 

For existing configurations, some of the decision factors in migrating to Flow Designer should be:

  • Will this future-proof my functionality? Is what we are using now still supported? Is it going to be deprecated soon?
  • Will this enable me to use native functionality to replace code/custom functionality I have written?
  • Will it make my functionality easier to maintain? Will it allow non-technical people to be involved in the process?
  • Will it be time-consuming / expensive to migrate what we have built-in without Flow Designer?

P.S. Script Includes are not included in this, they serve a unique purpose that cannot be replaced with Flows.