You are viewing limited content. For full access, please sign in.

Question

Question

message start event - More than one form

asked on July 11, 2016 Show version history

We have a case, when a public user needs to submit a form and starts a process, in the process diagram, a message start event is used to start the process (with a trigger on filling a form as usual).

However, we had to design two forms due to user language selection (AR & EN), so if user chooses the english language we should call the english form, where if arabic is selected we should call the arabic form, all other process tasks and activities should be the same regardless of the selected language (user tasks, approval, end etc...).

The process modeler allows only one message start event with one selected form only, any ideas on how can we do that?.

0 0

Replies

replied on July 11, 2016

Hello,

Javascript can Help you. The idea is to GET the content  english message and replace it with the arabic one. 

document.body.innerHTML = document.body.innerHTML.replace('EnglishText', 'ArabicText');

Not the best idea, but it can be good enough

 

 

0 0
replied on July 11, 2016

Thanks Ahmed, but as you mentioned it can maybe convert the text, but still i have to do for each field, and that won't solve the alignment.

All what I need to do is to avoid creating two duplicate processes for better maintenance.

0 0
replied on July 11, 2016

Hi Laith,

Currently there can only be one Start event for a Forms process; what you could do, however, is have as the starting form a form with a required language selector (English or Arabic) and set up an exclusive gateway afterward, where each of two paths corresponds to the language chosen. Each path will lead to a user task with the form set to the form in the appropriate language. Assign this user task to "Initiator".

Then, in the settings for the Start event, choose "automatically load the next task if the same person is assigned to it".

What will then happen is User will begin the process by choosing a language. Because User is the Initiator, and the next task is assigned to the Initiator, thanks to the setting in the Start event the next form should load, which would be the form in the appropriate language.

Hope this helps!

1 0
replied on July 12, 2016

Thanks James,

I though of that, but the problem is that in our case public (anonymous) users have to submit the form by calling the published process URL, so based on the solution above, the form will be displayed and assigned to a LF user.

One of the options was to provide in the URL the requested language as a URL parameter, the parameter can be captured on load and filled into a field at a starting form, then as per your solution above, with an exclusive gateway the appropriate form can be displayed, but again, the problem here is that only LF users will be able to submit.

0 0
replied on July 12, 2016

Thanks James,

I though of that, but the problem is that in our case public (anonymous) users have to submit the form by calling the published process URL, so based on the solution above, the form will be displayed and assigned to a LF user.

One of the options was to provide in the URL the requested language as a URL parameter, the parameter can be captured on load and filled into a field at a starting form, then as per your solution above, with an exclusive gateway the appropriate form can be displayed, but again, the problem here is that only LF users will be able to submit.

replied on July 12, 2016

Thanks James,

I though of that, but the problem is that in our case public (anonymous) users have to submit the form by calling the published process URL, so based on the solution above, the form will be displayed and assigned to a LF user.

One of the options was to provide in the URL the requested language as a URL parameter, the parameter can be captured on load and filled into a field at a starting form, then as per your solution above, with an exclusive gateway the appropriate form can be displayed, but again, the problem here is that only LF users will be able to submit.

replied on July 12, 2016

Thanks James,

I though of that, but the problem is that in our case public (anonymous) users have to submit the form by calling the published process URL, so based on the solution above, the form will be displayed and assigned to a LF user.

One of the options was to provide in the URL the requested language as a URL parameter, the parameter can be captured on load and filled into a field at a starting form, then as per your solution above, with an exclusive gateway the appropriate form can be displayed, but again, the problem here is that only LF users will be able to submit.

replied on July 12, 2016

Thanks James,

I though of that, but the problem is that in our case public (anonymous) users have to submit the form by calling the published process URL, so based on the solution above, the form will be displayed and assigned to a LF user.

One of the options was to provide in the URL the requested language as a URL parameter, the parameter can be captured on load and filled into a field at a starting form, then as per your solution above, with an exclusive gateway the appropriate form can be displayed, but again, the problem here is that only LF users will be able to submit.

You are not allowed to follow up in this post.

Sign in to reply to this post.