Skip to main content

Hi,

In a use case we want to prevent any changes in the Back Office on a Service Order when the technician do the ‘Start Activity” on mobileedge.
At this step, we would like that any modifications should be possible in the back office on the service order until the technician do the “stop activity” or resolve the SV.

I know that we have the workflow mobility that allows to do that when we dispatch the SV, but in this use case, the start event must be the “start activity”.
We aslo have a setting in workflow Service with the option Restrict Editing Rights from Status, but it’s too late for the use case.

Do you know a way to do that   ?

In the past Do you had any customer needs / requirements like that to do a BRD ?

Thanks and Regards
anthony

HI Anthony,

As you you correctly pointed out the workflow (mobile) starts restriciting the editing at the point of dispatch.  I believe to have it work at the point of start activity in place of dispatch would be a change request.

Whether there is an existing RFE for such, I can’t tell you myself but perhaps Reid can confirm this aspect.

Hi Anthony,
You may be able to use the Alliance Customizer to change the editable property on the fields individually based on the current value in the activity status but I’m not sure that can be used to broadly lock down all of the tabs and fields at once so I suspect this would need to be done as a customization request.  I’m not aware of any open RFE’s for this at this time.
Thanks,
Reid

I think this may be a little more complicated than what the description of the use case is described as so far… for example, the case states they don’t want any backend changes while the activity is in progress.

So this would mean potentially:

  • disable assign/dispatch (to reassign the agent)
  • disable exclude mobile to prevent the ticket from being retrieved
  • disable additional items added to the order while in progress

A general not allow editing at all would be a very large Customizer set up which I would have concerns about maintaining.  However, I think you also need to account whether the backend needs to create an additional work order, etc. so a general prevent may not be a good idea.

I think more realistic would be to identify which data should not be modified and then add those setup to the Customizer than trying to lock down everything that may cause an update redispatch which I am guessing is the pupose of the use case.

If the goal is to prevent redispatch thus losing the current work order data set on the mobile client that has not yet been uploaded from the client, I would look more to warning there is an activity in progress if the applied changes in the backend would result in a redispatch and not allow the changes.

In any case, it seems Reid agrees this would be a customization request that would have to be fully specified.

Hi @Reid Gilbert @Phil Seifert 

Thanks for your explanation and inputs. Phil , I agree with what you said. I already asked what fields and tabs could be impacted...still waiting the answer.
 

Regards

 

anthony

Reply


Terms & ConditionsCookie settings