I ran into a problem setting the outcome value (Field Decision) in a Flexi Task Nintex Form. In my example I have a simple FlexiTask with two Outcomes:
Reject, cause of
To make it easier for the User I set the outcome value to a button on my form (as i found here ). I found out that the value of the field Decision is set to the following:
Approved => 1
Reject, cause of => 2
So my buttons got these values assigned to the Decision field. As far as goot everything worked fine.
I now moved my Workflow including the FlexiTask form from my dev environment to the Integration (Export/Import). Doing this exchanges the outcome values for some reason to:
Approved => 2
Reject, cause of => 1
You can imagine this is a real mess...
Does anyone have a solution on this?
Of course I could. But we want to manage the deployment automatically... we will have more than 30 flexi tasks in about 20 workflows at the end and the way to get the decision values is very annoying.
I can't understand why the outcome value cannot be set on the FlexiTask Decision field manually... and why this value has to change in another farm?
We also want to hide other fields depending on the decision but this will also be very tricky.
I think about a JS solution to dynamically gather and set the value on submit but where I can find the expected without showing the Decision Option buttons?
Thanks fpr any suggestions
Maybe not a good one, but can try to use SQL to update ConfiguredOutcomes table in Nintex Workflow databases to be same as another farm. (Assume two different farm will have same ConfiguredOutcomes)
You can change the default radio buttons to display as "option buttons" instead. This would help you avoid having to create two new buttons and specifying their return values. Just double click on the radio buttons and select the option to "render as buttons".
This might help you get around the behavior of having to deal with the different values and hard-coding them on your buttons.
Thanks for this hint - as all farms belongs to the same project (test-, integration and productive environment) this solution fits for our needs and the usability for the user is as it should: Only press one button instead of selecting the outcome and press the confirm button...
Thanks for this info, very useful!
I just checked and this is a Nintex Content database table (not a Nintex Config database table) and therefore it could vary from site collection to site collection, let alone from farm to farm.
I'd suggest using a Site Collection scoped Workflow Constant to specify these values and then use those values in your Forms / Workflows. The description of the constants created should contain enough info to clarify to anyone using the constant that it is based on Nintex content database values and thus needs to be rechecked / repopulated every time the constant is used in a new site collection and/or farm.
we decided to update Nintex database to get always the same values because our deployment shall be 100% automated using PS.
Here is our script:
USE DBNAME -- <-- <INSERT DATABASE NAME HERE
SET IDENTITY_INSERT dbo.ConfiguredOutcomes ON
-- Delete existing
DELETE FROM dbo.ConfiguredOutcomes
WHERE Id IN (1,2,4,5)-- <-- Insert new ID's here
-- Insert new
INSERT INTO dbo.ConfiguredOutcomes (Id,Name)
(2,'Reject, cause of'),
-- <-- Insert new Id's here
SET IDENTITY_INSERT dbo.ConfiguredOutcomes OFF
I love automated deployments, but I'd very strongly recommend against writing to the Nintex databases. If Nintex update their schema in a future update, then your process could have unexpected consequences and essentially corrupt the database.
The creation of your Flexi-tasks should automatically provision the rows in the table. You can then read the values in order to set up the Workflow constants. This would in theory all be completely automatable, without writing directly to the database.
Hi Martin - thanks for your warning.
> but I'd very strongly recommend against writing to the Nintex databases
I'm aware of tis behaviour and we will keep this in mind in future releases of our solution.
> ...You can then read the values in order to set up the Workflow constants...
Where to read the values? If this is from database we could run into the same issue when database schema changes in future...