You’re offline. This is a read only version of the page.
Workflow conditions do not seem to be working in the environment.
The workflows themselves are working but we were unsuccessful when trying to apply conditions to steps.
For Example:
• The Step type is Approval
• It’s a first step.
• Action is required only when the following condition is met:
• Condition “where Purchasing Requisition Work.Domain User Name is ‘User X’.
• If the condition was not met, the option chosen was ‘End workflow path’.
• The step as assigned to ‘User X’. [My typo - this should be 'User Y']
• Additional details are that an approval is always required.
When we entered a requisition with ‘User X’ it goes directly to the workflow manager for approval instead of User Y who is the approver.
We then subsequently more generic Conditions just to test other scenarios for example:
• Where Purchase Requisition line.Item Number is ‘TEST’ (A Requisition was then entered with the Item number as ‘TEST’)
• Where Purchase Requisition line.Quantity Ordered is ‘1.00’ (A requisition was then entered with the Quantity Ordered as ‘1.00’)
The results were the same in that the requisitions were routed directly to the Workflow Manager.
Anyone had this issue before?
*This post is locked for comments
Hi Derek, I am not using the dex ini mod.
I will check the workflow history and advise as soon as i get connected.
If you have the option marked on the workflow where at least one approver is always required, then it will attempt to route the workflow to first the alternate final approver if one is specified and if not, then to the overall workflow manager, as a manager is always required, if one or both of the following occurs:
1. In this case, it looks at the workflow conditions and doesn't deem them as true, thus requiring approval, so it doesn't route to the specified approver, but instead will go to the alt approver or workflow manager.
2. This can also happen, though less so, if workflow can't validate the approver(s) as being valid, so it routes the workflow to the alt approver or workflow manager. Though in most cases, if this is true, it will reject the workflow outright.
When you add the conditions and the workflow is routed to the workflow manager, what does it show in the workflow history for that requisition? Does it show the step actually requiring approval based on the conditions entered, or does it show 'no action needed' before being routed to the workflow manager?
If it is a matter of the conditions not working, so that workflow doesn't think approval is needed based on those conditions, what we would do is run a SQL Profiler trace capturing this issue, then look for a qdCreateSQL procedure which Workflow uses to generate a SQL SELECT query, which will return either a value of '1' (requires approval) or '0' (no approval needed), to find the SELECT statement being generated and then run it manually in SQL against that company database to determine why it's returning an incorrect value.
One other thing I'd like to verify is whether or not you've used or are currently using the Workflow Condition Editor or not?
I.e. have you entered the following line in your Dex.ini file and launched Dynamics GP with it? QueryDesignerAllFuncitonality=TRUE
The reason I ask is because we've seen an issue when extending the functionality of the Workflow Condition window with this line in Dex.ini, which causes GP to generate a script that runs to get the '1' or '0' value I mentioned above to determine whether approval is needed or not, but what happens is that it adds lines for GL in the script, which isn't related to requisitions at all, thus the script will always return a '0' value, thus deeming it as no approval needed based on the conditions.
If you are using this extended functionality, on your requisition workflow steps, click on the lookup button for the approval condition to open the 'Workflow Condition Editor' window.
In this window, you'll see a series of tabs across the top which you normally wouldn't have by default.
Click the 'Link Tables' tab and it should show you the tables and join statements that it is using to pull the approval condition information from.
What you want to look for, is to see if you have the following lines in your condition script:
Purchasing Requisition Line INNER JOIN GL_Account_Index_MSTR WHERE
Purchasing Requisition Line.Inventory Index = GL_Account_Index_MSTR.Account Index
If you do, make a copy of the entire script as a backup, and then remove these two lines, save changes and then see if your purchase requisition workflow flows as expected depending on what approval conditions you have setup.
Please let me know if you have any questions on anything I mentioned here.
Thank you,
Hi Derek,
Yes, once no conditions are applied, It routes to the specified approver when “always require approval” is selected.
It’s only when conditions are applied, its routed to the Workflow Manager.
We would probably need a support case to look at it then...….basically what is happening is that Workflow uses a stored procedure that runs a SELECT statement based on the workflow type and approval conditions, the script returns either a '1' value meaning approval is needed or a '0' value meaning no action needed. This is done per workflow step. We usually need to run a SQL Profiler trace to find the SELECT statement, then manually run it in your GP company database to determine what the cause of the issue is.
One other question, if you set the workflow step to always require approval, not using any type of conditions at all, does it then route to the specified approvers on that workflow step, or does it still get routed to the workflow manager?
Thanks
Hi Derek,
My apologies, the requestor is not an approver.
I am not sure that the domain name is making an issue because we used other conditions to test and it still did not work. Any other suggestions?
Excerpt from above:
We then subsequently more generic Conditions just to test other scenarios for example:
• Where Purchase Requisition line.Item Number is ‘TEST’ (A Requisition was then entered with the Item number as ‘TEST’)
• Where Purchase Requisition line.Quantity Ordered is ‘1.00’ (A requisition was then entered with the Quantity Ordered as ‘1.00’)
The results were the same in that the requisitions were routed directly to the Workflow Manager.
First question, you mention the workflow step is assigned to 'User X' for the approver, is User X the user that is submitting the requisition through Workflow? If so, do you have the option marked to allow originators to also be approvers? If not, then even if the workflow step in the above example required approval, it would not allow User X to be the approver for it, because that user submitted it, thus it would attempt to route the workflow step to any alternate final approver specified and if there isn't one, the workflow manager, for approval, which is pretty much what you're seeing happen.
Also, I know I have had at least one case where the customer was attempting to use Domain User Name as the approval condition and workflow didn't like the fact they had a period (.) in the name, such as 'John.Doe', so we changed the condition to be something like require approval when Domain user Name contains 'Doe', then it began working as we expected it to.
Lastly, for the Purchasing Requisition Work.Domain User Name condition, I believe you need to use the full domain\userID format if you're using an equal sign, not just the name of the user, similar to if you open the Command Prompt window and type in 'whoami', and click Enter, it'll show you the full domain\userID format.
I.e.....
Where Purchase Requisition Work.Domain Name = 'DomainName\UserID'
compared to.....
Where Purchase Requisition Work.Domain Name contains 'UserID'
Thanks
Stay up to date on forum activity by subscribing. You can also customize your in-app and email Notification settings across all subscriptions.
#1
André Arnaud de Cal...
291,253
Super User 2024 Season 2
#2
Martin Dráb
230,188
Most Valuable Professional
#3
nmaenpaa
101,156
Share
Report
All responses (
Answers (