Multiple checkout workflows

May be this question was already answered, if it was, please close this one and point me to the proper topic.

Question is:
Lets say I want to have two different workflows for checkout, one involving lets say extra steps, and other one the default one that comes with the platform.

Now, some customers (probably by customer group) should use one and other customers should use the other one.

Lets say, Customer Group A should use the default workflow that comes with Oro., Customer Group B should use the Custom Workflow.

How this can be configured?
Does this require some coding?

Any insights on this will be more than welcome.

Thanks in advance!

Pablo.

• This topic was modified 5 years, 2 months ago by  pcianci. Reason: Typo

Topic

[MichaelKeymaster]

Hi Pablo,

The workflow engine allows to do scoping of workflows based on virtually any criteria.
At this time scopes are not exposed in the workflow management UI though.
You can modify workflow scopes by either defining scope in the workflow configuration file before importing it (e.g. see the workflow configuration file documentation and our sample checkout workflow with approvals, which replaces regular checkout flow for Customer with ID = 4)

Alternatively, one can build a simple UI to manage it, as to restrict workflow scope for the existing scoping criteria you would only need to add new entries to oro_scope and oro_workflow_scopes tables in the database.

The existing criteria in a non-customized out-of-the-box OroCommerce installation are:

• customer – by customer, this one is used as an example in our sample checkout workflow with approvals
• customerGroup – by customer group
• localization – by localization (the language currently used by the user)
• website – by website, in the OroCommerce Enteprise Edition with multi-website functionality

Developers can also introduce their own scopes. You can check ScopeCustomerGroupCriteriaProvider and LocalizationScopeCriteriaProvider if you are a developer and look for examples of how to do it.

Please note that workflow scope is not the only way to implement such restrictions. A different approach with preconditions on workflow start transitions in combination with is_unavailable_hidden flag may be a good alternative for some use cases as well.

[MichaelKeymaster]

And one more thing, that may be useful to someone who stumbles upon this thread is that role-based permissions on workflows, both for backoffice users and storefront customer users, can be configured in the UI – https://oroinc.com/b2b-ecommerce/doc/current/admin-guide/workflows#user-permissions-for-individual-workflows

[Author]

Replies