FlexiTask outcome value (Decision) changes

  • 11 December 2014
  • 12 replies
  • 25 views

Badge +6

Hi,

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:

Approved

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?


12 replies

Badge +11

It says in that article that the IDs of the outcomes are not the same on every farm.

Can't you just use the new IDs?

Badge +6

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

Userlevel 5
Badge +12

Hi Roman,

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.

-Mike

Badge +6

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...

Badge +2

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.

Badge +6

Hi Martin,

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
GO

-- 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)
VALUES
(1,'Approve'),
(2,'Reject, cause of'),
(4,'Approved'),
(5,'Reject')
--                                   <-- Insert new Id's here

SET IDENTITY_INSERT dbo.ConfiguredOutcomes OFF
GO

Badge +2

Hi Roman,

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.

Cheers,

Marty

Badge +6

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...

Badge +2

Yes I mean read the values from the database.

You're absolutely right - if Nintex change the schema then this read process could also be in error, but the impact of an erroneous database read will always be far less than the impact of an erroneous database write.

Badge +2

Hi.I have the same issue, the task outcomes are switched when I deploy in test environment. Is there any other solutions yet. I dont want have the decisions as buttons, because the user had to click decision button and "OK" button to submit the form.

Please advise.

170266_pastedImage_1.png

Thanks

Senthilselvi

Badge +9

Thanks for providing this script. Do you have a quick script that you can share with us to just retrieve those codes and the corresponding outcomes (but not actually change them)? 

Badge +4

If you want to know what the outcomes are listed as and their IDs you can use the below script to do so.

select * from ConfiguredOutcomes

Be sure you're connected to the server and the correct nintex workflow database before executing. These can be found in your central administration if you don't know them.

 

With that note however, we did make a change to this list on our server and while this database shows "Cancelled" as ID 4, when I use decision = 4 as integer it is not using the appropriate outcome. Does anyone know of a way to make the site re-read the list into memory? It seems to be still using our old list. We're trying to make sure this one matches our production envrionment list of outcomes for when sites are created. (I originally dropped the table and then re did the values based on the production server's list of outcomes and IDs since the ID value was auto numbering.) I just did one as ID 5 and it shows "delegated" where the DB table doesn't even have delegated on the list of rows...? 

 

I can't say this database accurately reflects what's in your decision list, but if you haven't changed the database table, then it SHOULD accurately reflect the decision IDs in your envrionment unlike mine.

 

Reply