New April Hotfix and more changes for VAT
Check out the latest updates to Microsoft Dynamics GP 2016 and 2018.
Dynamics 365 2019 release wave 2 plan Discover the latest updates to Dynamics 365.Release Plan | Weekly Deployment Notes
Ace your Dynamics 365 deployment with packaged services delivered by expert consultants.Explore service offerings
Connect with the ISV success team on the latest roadmap, developer tool for AppSource certification, and ISV community engagements.
ISV self-service portal
The FastTrack program is designed to help you accelerate your Dynamics 365 deployment with confidence.
FastTrack Program | Finance and Operations TechTalks | Customer Engagement TechTalks | Talent TechTalks
This is the last of the three blogs covering the Workflow User Setup window used to assign approvers in the new Workflow 2.0 feature found in Microsoft Dynamics GP 2013 R2.
The other two blogs can be found here:
--Workflow 2.0's Workflow User Setup window options: part 1: People and Groups
--Workflow 2.0's Workflow User Setup window options: part 2: Hierarchy
We're still using the same scenario of setting up the new Workflow 2.0 functionality in Microsoft Dynamics GP 2013 R2, whether it be a Purchase Order Approval, Purchase Requisition Approval, Payroll Timecard Approval or Project Timesheet Approval workflow type.
For this example, we're using the Purchase Requisition Approval workflow type, with a domain name of 'CONTOSO' and Active Directory users: CONTOSO\USER_A, CONTOSO\USER_B, CONTOSO\USER_C, and CONTOSO\USER_D.
To select an approver for this first step of the Purchase Requisition Approval workflow, we click on the lookup/magnifying glass button next to the 'Assign To' field, which opens the Workflow User Setup window.
In the Workflow User Setup window, for the 'Selection Type' field, this time, we're choosing the 'Workflow Role' option, which then enables a 'Workflow Role' field as well.
When we're using the Workflow Role option for Selection Type, we're telling Workflow 2.0 that we want the approver of the submitted documents and batches to be that Windows user account that is currently assigned to that position or role.
The options we have for Workflow Roles are the following:
>>Workflow Originator - When this role is selected as the approver, and in this case, a requisition is created and submitted for approval, the requisition is then assigned to the Windows user account that the user is logged on the machine as, while in Microsoft Dynamics GP 2013 R2, creating and submitting the requisition for approval through the Purchase Requisition Entry window. (Transactions > Purchasing > Purchase Requisition).
>>Workflow Manager - When this role is selected as the approver, in this case, a requisition created and submitted for approval, the requisition is then assigned to the listed manager in Active Directory, for the Windows User account the user is logged on the machine as, as listed in Active Directory, while in Microsoft Dynamics GP 2013 R2, creating and submitting the requisition for approval through the Purchase Requisition Entry window.
>>Alternate Final Approver - When this role is selected as the approver, in this case, a requisition created and submitted for approval, the requisition is then assigned to the Windows user account selected as the 'Use alternate final approver' in the Workflow Maintenance window. In this example, I have USER_D listed as the alternate final approver, so the requisition will be assigned to this user for approval.
>>Requested By - After setting up and activating the Purchase Requisition Approval workflow type, requisitions are then created and submitted for approval via the Purchase Requisition Entry window (Transactions > Purchasing > Purchase Requisitions. In this window, on the header part at the top, there is a 'Requested By' field as well as another 'Requested By' field in the Line section of the window, which is considered the Line Requested By. Because this field is populated by the GP account you're logged into Microsoft Dynamics GP 2013 R2 as, Workflow 2.0 will look at the Windows user account the user is logged on as, and make that user account the approver.
>>Line Requested By - This option works the same as the 'Requested By' option.
An example of how this all works is, for an example, let's say we have the following setup in Active Directory:
User_A, who's manager is setup to be User_B
User_B, who's manager is setup to be User_C
User_C, who's manager is setup to be User_D
While logged into Windows as User_A, we're going to create and submit a requisition through Dynamics GP 2013 R2 / Workflow 2.0 for approval.
For the approver, we're going to setup the Workflow User Setup window to use 'Workflow Role' for the Selection Type, then select 'Workflow Originator' for the Workflow Role. When we submit a requisition for approval, the system will look at the Windows user account that we're currently logged onto the machine as, while running Microsoft Dynamics GP 2013 and attempt to assign the requisition to it for approval. In this case, User_A.
***NOTE: In order to have the Windows account that we're logged onto the system on while submitting a requisition for approval, (The Workflow Originator), be the approver for that same requisition, in the Workflow Maintenance window, we must have the 'Allow originator to be an approver' option marked, otherwise instead of making the Workflow Originator the approver, it will default to the manager of the overall Workflow type, in this case Purchase Requisition Approval.
This is true regardless of which Workflow role is selected, and in any case where the user account submitting the document or batch for approval is also going to be the approver of those same documents/batches.
So, with the 'Allow originator to be an approver' option marked, if we have 'Workflow Originator' selected, the submitted requisitions will be assigned to the Windows user account the user is logged onto the machine as, while logged into Microsoft Dynamics GP 2013 R2 submitting the requisition.
If we choose 'Workflow Manager' for the role, any submitted requisitions will be assigned to the manager of the Purchase Requisition Approval workflow type, which in this example would be the USER_D Windows account.
If we choose Alternate Final Approver' for the role, any submitted requisitions will be assigned to the Windows account we have setup as the 'Use alternate final approver' field, in Workflow Maintenance window:
If we choose 'Requested By' or 'Line Requested By' for the role, any submitted requisitions will be assigned to the Windows user account that is logged onto the machine while using Microsoft Dynamics GP 2013 R2 and, in this case, Purchase Requisition Approval workflow to submit requisitions for approval. Because the 'Requested By' fields in the Purchase Requisitions window both populate with the GP user, not the Windows user, so there's no Active Directory to pull the GP user from, it instead looks at the Windows user account the user is logged on as when submitting the requisition instead and will use that user, again, depending on whether or not the 'Allow originator to be an approver' option is marked or not.
--If, for any reasons, Workflow 2.0 cannot verify a Window user account's direct manager in Active Directory or the user doesn't have one designated, the application will default to the Windows user account itself, not its manager.
--If, for any reasons, Workflow 2.0 cannot verify a Windows account in Active Directory, it will default to the overall Workflow type manager as designated in the Workflow Maintenance window.
Hopefully these blogs have addressed many of the questions you may have in setting up the new Workflow 2.0 functionality available in Microsoft Dynamics GP 2013 R2. I feel once you understand the information in these three blogs regarding how to correctly setup the approvers you want to have, you'll have a pretty good grasp on setting up the new workflows.
I just created a product suggestion for requisitioners to view only requisitions that are assigned to them rather than just having an option to view ALL or Requested by User.
Here is the link for the product suggestion if you would like to add some votes to push it to the top of the list, that would be great.
I definitely see what you mean in regards to not being able to see the open requisitions when set to 'Requested By' but when set to 'All Open' the users can then see all requisitions submitted, even where they are not the approver.
Unfortunately, there isn't any change in the works for this at this time, but I would highly suggest going into the Product Suggestions and if this isn't already an ask, create it and have everyone vote on it, otherwise vote on it if the suggestion is already there, as the more votes a suggestion gets, the more likely it is to be included in a future release of Dynamics GP.
PRODUCT SUGGESTION: Is there an enhancement you’d like to see considered? Use the link below to voice your opinion. Every suggestion is read and triaged by the Dynamics GP Development Team. Or vote on an existing suggestion, as the more votes they get, increases the priority rating on it.
I am having the same issue as Patrick and Jon have indicated. The approvers are able to see all other requisitions in the system including their own. This is a big issue in cases where there are requisitions being submitted by management / executives where others do not need to know the amounts and reasons.
Has anyone found a work around for this or heard of any upcoming fix to resolve this? Greatly appreciate any comments / suggestions.
I was wondering if there was any way to limit the account numbers to that department only so perhaps that would restrict the requisitions they have access to?
Unfortunately, this behavior is the same, even in Dynamics GP 2015 R2.
Either the users can see the requisitions that are 'Requested By' them, or 'All Requisitions'.
I would recommend searching for this to see if it has been submitted as a product suggestion and if so, vote on it, or if not, enter it so others can vote on it, as it sounds like there are customers and partners that want this changed in Workflow 2.0 functionality.
Business Applications communities