Home > Forum > Tips&Tricks > Cloning an app or workflow

Cloning an app or workflow
0

I have created an app and a dictionary. Now for this app, i have to create same process, but with different set of users. What is the best way to do it?
1. Clone the workflow, set it a Custom Instance number and modify steps with the new group of users?
2. Clone the process?
3. Export that app as a template? But when i want to import it, i have to use that dictionary i have created.

Thanks

MVP

Hi AndreeLi,

the best way would be to avoid the duplicated process, but that's obviously an answer from someone who doesn't know your use case.

Maybe you could elaborate on these questions:
1. Do you only need to change the task assignment?
2. Are different privileges are assigned in the Designer Studio like who can start workflows?
3. Does this apply only to this single application or would this apply to others too?
4. Are these users in the same company as the others?

The reason why I'm asking these questions are:
1. I never hard code task assignment to users or BPS groups. Either there are roles (fields) defined on the process or business rules are used to get the correct user/group. These could even be returned from a dictionary.
2. If you need to assign different privileges on a general level there would be options to use either form types or business entities.


Best regards,
Daniel

In reply to: Daniel Krüger (Cosmo Consult)

Hi AndreeLi,

the best way would be to avoid the duplicated process, but that's obviously an answer from someone who doesn't know your use case.

Maybe you could elaborate on these questions:
1. Do you only need to change the task assignment?
2. Are different privileges are assigned in the Designer Studio like who can start workflows?
3. Does this apply only to this single application or would this apply to others too?
4. Are these users in the same company as the others?

The reason why I'm asking these questions are:
1. I never hard code task assignment to users or BPS groups. Either there are roles (fields) defined on the process or business rules are used to get the correct user/group. These could even be returned from a dictionary.
2. If you need to assign different privileges on a general level there would be options to use either form types or business entities.


Best regards,
Daniel

Yes, i only need to change the task assignment.
For example, i want to create 2 start buttons: 1. for IT ; 2. for Economics. There will be 2 different groups (IT and Economics). It is same process, but user may want to start an ordering request for IT group.
Now the app has a group where there is all people included (IT and Economics). It is a little bit frustrating to see tasks, even though they are not meant for you. And now i want to create another workflow, i guess? which i will modify to be for IT group. That's why i am asking which is the best way.
If i clone a workflow, what could happen?

MVP
In reply to: AndreeLl B

Yes, i only need to change the task assignment.
For example, i want to create 2 start buttons: 1. for IT ; 2. for Economics. There will be 2 different groups (IT and Economics). It is same process, but user may want to start an ordering request for IT group.
Now the app has a group where there is all people included (IT and Economics). It is a little bit frustrating to see tasks, even though they are not meant for you. And now i want to create another workflow, i guess? which i will modify to be for IT group. That's why i am asking which is the best way.
If i clone a workflow, what could happen?

Hello everyone,
In this case i'd consider just conditional task assignment. As Daniel already pointed out, you can use Buisness Rules for that.

On the form you could add a dropdown with 2 values:
* Order for IT
* Order for Economics

And in the Buisness rule you just go with
IF Order for IT then Users [ here people/groups from it ]
IF Order for Economics then Users [ here people/groups from economics]

In task assignment just use that buisness rule.
(it's just an example, you could use another form, technical field, checkbox, basically anything on what you can make condition)

Creating Roles with Buisness Rules is really clean solution, good to use even, when there are no conditions yet.

MVP
In reply to: AndreeLl B

I understand, thank you.

But in my situation i currently have only one environment. So the only way to develop is in Production. And app is in use right now.
If i do something wrong, app won't work. If i just cloned that workflow, it would not have affected the current worfklow/app.

So i don't know...Any ideas?

In this case I would do the following:

1) Add global constants for the Ids of the groups
2) Create a field for example "Responsible department" where those groups are used.
3) Use the field in the task
4) Add a start tile for those groups settings the id of the group as a default value.

I'm not sure, whether I would allow editing the field in later steps, this would depend on the actual use case. Probably I would allow it, in case someone did something wrong.
Depending on the number of running instances which need to pass through the steps I would either update the instances in admin mode or use a "update workflow action", if it's more than 100 or so.

If it's not a heavily used workflow, meaning, you can tell the people that they can't use it for 30 minutes, I would just update it.

If it's a more complex application you could
- verify that the start title target the real workflow
- clone the workflow change the signature
- assign the same form type
- add the field only to field matrix to the cloned workflow
- modify the steps
- add a new start action which is only visible to you and test it.

Afterwards you can repeat the changes in the real workflow.

Best regards,
Daniel

In reply to: Daniel Krüger (Cosmo Consult)

In this case I would do the following:

1) Add global constants for the Ids of the groups
2) Create a field for example "Responsible department" where those groups are used.
3) Use the field in the task
4) Add a start tile for those groups settings the id of the group as a default value.

I'm not sure, whether I would allow editing the field in later steps, this would depend on the actual use case. Probably I would allow it, in case someone did something wrong.
Depending on the number of running instances which need to pass through the steps I would either update the instances in admin mode or use a "update workflow action", if it's more than 100 or so.

If it's not a heavily used workflow, meaning, you can tell the people that they can't use it for 30 minutes, I would just update it.

If it's a more complex application you could
- verify that the start title target the real workflow
- clone the workflow change the signature
- assign the same form type
- add the field only to field matrix to the cloned workflow
- modify the steps
- add a new start action which is only visible to you and test it.

Afterwards you can repeat the changes in the real workflow.

Best regards,
Daniel

Thank you very much for your answer.

But i am curious what would happen if i just clone a workflow and change its Instance number ( having a Custom acronym/Year/Month/Day/Nr) and update steps with the new group email, then create a starting button for that workflow and use it. Is that such a bad idea?

MVP
In reply to: AndreeLl B

Thank you very much for your answer.

But i am curious what would happen if i just clone a workflow and change its Instance number ( having a Custom acronym/Year/Month/Day/Nr) and update steps with the new group email, then create a starting button for that workflow and use it. Is that such a bad idea?

Hi,

Ok, let's ignore the fact that you would need to replicate any change in the cloned workflow.

The cloning will generate new ids for every element. The most relevant would be
- Workflow
- Steps
- Paths

Are you using any of these information in any automation / view / data table field or whatever? If the answer is yes, you would need to change these to reflect both workflows where applicable. Examples:
- Change reports / views. Of course, this could be something you could want.
- Mass action on the report which are defined for a path
- If the workflow is used in a "create subworkflow action"

Regardless of what you choose, in my experience the user seldom look at the information panel but focus instead on the main content area of the page. Therefore I would add this "Responsible Department" field anyway, so that they are aware of what will happen.

Best regards,
Daniel