Dynamics 365 Supply Chain Management WHS extending. Adding a new work type for "User directed" mobile device flows.

Introduction

I would like to share my experience with adding a completely new work type. In my case, I have added a new work type for "User directed" mobile device flows. My post is not a complete guide on how to do it. It is more about the main idea and some thoughts. 

Note: There is a post on how to work with the “Custom” work type. It is different.

Overview

WHSWorkType enum extending

First, it is necessary to extend the standard "WHSWorkType" enum in order to add a new work type.

Adding new mobile device step

Then, since it is a new work type it makes sense to add a new step so that the system can process the new work type. The new step should not have one of the existing numbers in the standard macro “WHSWorkExecuteDisplayCases”. 

We can create a new macro or use an existing one for this purpose and add a new step:

#define.NewWorkStep(10000)

Adding a new class handler for the new work 

After that, we need to create a new class handler for the new work type:

/// <summary>

/// The <c>WhsNewWorkTypeHandler</c> class handles new work type.

/// </summary>

[WhsWorkTypeFactory(WhsWorkType::NEWWorkType)]

class WHSNewWorkTypeHandler extends WhsWorkTypeHandler

{}

In this class, we need to implement the methods:

• findWorkCreateLocationQty – sets the parameters of the processing.
• determineStep – defines the first step of the flow for the work type. Also, you can add a mobile device screen to be shown for users.
• executeWorkLine – defines the actions with the work line.

Note: In the system, there are “WhsWorkTypePrintHandler” and “WhsWorkTypeCustomHandler” classes that can be used for a better understanding of the work type handler classes.

Below is a mockup of the possible solution:

public WhsWorkCreateLocationQtyResult

    findWorkCreateLocationQty(WhsWorkCreateLocationQtyParameters _parameters)

{

   WhsWorkCreateLocationQtyResult result; 

   

   result = WhsWorkCreateLocationQtyResult::construct();

   result.locationId       = '';

   result.pickUnitId       = _parameters.unitId;

   result.pickQty          = _parameters.qtyWork;

   result.inventPickQty    = _parameters.inventQtyWork;

   return result;

}

public void determineStep(WhsWorkStepContext _context)

{

    WhsWorkExecuteDisplay   workExecuteDisplay = _context.workExecuteDisplay;

      

    //we can to go to the custom dialog if we would like to

    _context.nextForm   = workExecuteDisplay.DrawNewScreen();

    _context.step       = #NewWorkStep;

}

public WHSWorkLine executeWorkLine(WhsWorkExecute     _workExecute, 

                                   WHSWorkLine        _workLine, 

                                   WHSUserId          _userId)

{

    return _workExecute.processNewWorkType(_workLine.WorkId, 

                                           _workLine.LineNum, 

                                           _userId);

}

When we implement the handler class and the new step in the mobile device flow for the new work type we need to be able to process the new step correctly.

WhsWorkExecuteDisplay class extending

If we take a look at the "processWorkLine" method of the "WHSWorkExecuteDisplay" class we will see that there is a default section for new mobile device steps.

default:

   boolean finishedProcessing = this.processWorkLineForCustomStep(state);

   

   if (finishedProcessing)

   {

       return [state.nextForm, step, state.recall, pass.pack()];

   }

   break;

So, the next step is to create an extension of the WhsWorkExecuteDisplay class and implement the "processWorkLineForCustomStep" method. The "processWorkLineForCustomStep" method has the "Replaceable" attribute so in your extension you can write any business logic

Note: I would recommend using the “next” command in the “processWorkLineForCustomStep”, for instance:

protected boolean 

        processWorkLineForCustomStep(WhsWorkProcessWorkLineState _state)

{

    boolean    ret;

    ……………………………………

    switch (step)

    {

               case #NewWorkStep:

           //do something

           ret = true; //in case the step has been processed correctly

           break;

       default :

           ret = next processWorkLineForCustomStep(_state);

    }

   

    return ret;

}

In this case, if there is more than one extension of this method (for example, from multiple vendors) all of them will be called by the system. 

If you don’t call the “next” command, only your method extension will be called. All other method extensions can be ignored by the system.

If the new step has been processed correctly it is required to return the "True" value. In this case, the system returns the values from your method in the mobile device flow and the standard code after the "processWorkLineForCustomStep" is not executed.

When you jump into your new step you can develop your own mobile device screens and switch between them depending on the buttons and controls in use. When you are done with the new work type you need to "go back" to the standard mobile device steps.

Conclusion

For sure some code adjustments and extensions can be desirable in other objects too. It depends on the business logic that is planned to be implemented with a new work type. In my opinion, the text above can be used as a high-level guide.

Workflow Issue: Stopped (error): X++ Exception: Work item could not be created. Insufficient security permissions for user XXXX. Please review the user's security permissions to ensure they are sufficient for this workflow document and then resume the workflow.

Recently, we experienced a workflow security issue when the new D365 update was installed. Originally, the workflow process was copied from one of the standard ones and had worked for at least one year.

The error message was:

Workflow Issue: Stopped (error): X++ Exception: Work item could not be created. Insufficient security permissions for user XXXX. Please review the user's security permissions to ensure they are sufficient for this workflow document and then resume the workflow.

The first idea was that there are some changes in the standard Workflow process that we should apply. But there were no changes. We read the standard documentation and this article on the workflow security.

We searched the Internet and found a lot of posts and articles on this error.

Below you can find a list of possible reasons for the error:

1. User doesn't have approval rights (Approval related security is not assigned)

2. User doesn't have access to the menu item associated with workflow.

3. No employee is mapped to the user.

4. There is a dynamic rule assigned to the user that prevents this user from doing the operation.

5. The menu items specified on the approval or task elements for the step in the workflow have their configuration key disabled.

Unfortunately, all those options did not apply to our case.

We tried:

• Operations "Data > Synchronize all" and "Data > Repair" on the "Security Configuration" form. 
• Re-assigning user roles. (System admin > Security > Assign users to roles)
• Applying the "System administrator" role to user accounts as much as possible.

and so on.

Finally, we were able to find the cause of the issue. The error message says that it is a security issue but, in our case, it was a workflow query issue.  Users have started doing documents a bit differently and the query inside our workflow returned no record. The system interpreted this case as a security issue and raised the security error.

So, the lesson is: It can be not only about security permissions or configuration keys. If you see this error it makes sense to verify that the workflow query returns data.