James Gallally Posted January 6, 2021 Posted January 6, 2021 Hello, I have a number of BPM's that have the same issue. In the PCF, I have a Custom form that has a Static Radioset (for ticket priority - high/medium/low). This gets captured, and then in BPM there is a decision tree that initiates various actions depending on the priority selected. I thought it was working fine, and that just one particular BPM was not working as intended, but it turns out that any BPM that has this logic in takes the path of no match Can an outside pair of eyes spot the obvious mistake that I have done? PCF name = PCF Form details = PCF Properties = PCF = Radioset BPM Decision logic BPM expression I am using Display value (although I have tried RAW). Looking at the expression I am using the correct PCF, custom form, details and output. I am getting the PCF answers via Get -PCF Responses I was just about to submit this post when I thought I would double double check again to make sure I wasn't missing something, and discovered something that I really don't understand. The twist in the plot is that if the incident is logged via the self service portal, it works fine, and whatever priority is capture is set, however if I as a technician log the ticket on someone else behalf (or as me as the customer) using the exact same catalogue item, when the ticket is logged the BPM follows the No Match path. Anyone have any ideas? Thanks James
James Ainsworth Posted January 6, 2021 Posted January 6, 2021 Hi James, Thanks for your post. It may be a challenge to investigate without having copies or access to your Progressive Capture and BPM workflows. I do see that you have Premier Support, so if you don't get a response here, it may be worth raising a request with the Support team. Interesting about your last comment where it appears to work when the Service Portal is used, but not when a technician logs through the main app. Out of curiosity, are you using more than one language within your Service Desk?
James Ainsworth Posted January 6, 2021 Posted January 6, 2021 As it is working for users on the Service Portal, I would start with confirming the path being used for the progressive capture. When user on the Service Portal starts raising their ticket the service is already known and a particular Progressive Capture will be used, based on the Request Catalog Item. When an agent starts logging a ticket on behalf of a user, they will potentially have a different starting point as the Service is not pre-selected as it is in the Service Portal. Their initial Progressive Capture will be different. It may be the generic or default Progressive Capture associated to the Raise New option, or it could be a default progressive capture set to a particular request type such as when you raise a new Incident . There are settings available that let you turn off either the Raise New option or to hide all the the different request types in the drop list. May allow you to control the path that the agents take when raising a ticket so that the outcome is consistent.
James Gallally Posted January 7, 2021 Author Posted January 7, 2021 Thanks @James Ainsworth. I have turned on app.request.raiseNew.hide so we have to select Incident to ensure this is known first and I still get the same issue. Thanks
Adrian Simpkins Posted January 7, 2021 Posted January 7, 2021 Hi James, I presume you have a Raise new progressive capture in place referencing the catalogue item so that if it is raised internally the questions all trigger correctly to capture the priority? This is set under Service manager setting app.itsm.progressiveCapture.newRequest and app.itsm.progressiveCapture.newRequestFromEmail. If there is no logic here to point to the catalogue item the request will raise with no data and will take the default path, and if all requests are taking the no match path it may be this that is causing the issue. Thanks
James Gallally Posted January 7, 2021 Author Posted January 7, 2021 Thanks @Adrian Simpkins, I have followed the process/logic through from app.itsm.progressiveCapture.newRequest and it all looks correct. Strangely, almost all of my progressive captures work when used by technicians, there is only one (plus a duplicate of it for testing) that do not follow the process and get caught by my default PCF. 1
Steve Giller Posted January 7, 2021 Posted January 7, 2021 @James Gallally Have you tried deleting the Decision node and recreating it from scratch? This may simply be due to the way the image has rendered, but your BPM condition appears to contain TicketPriority -> Ticket Priority where the form appears to contain Ticket Priority -> Ticket Priority, and the Field ID is CallPriority (rather than TicketPriority) This could be a red herring, but could also be caused by copying from another BPM (or within this BPM) or by changing the PCF form after the BPM was created, so it's worth testing.
James Gallally Posted January 8, 2021 Author Posted January 8, 2021 Thanks @Steve Giller. I don't think that I am actually hitting the right PCF when I log a call on behalf of someone. Looking at app.itsm.progressiveCapture.newRequest, this calls Which runs this very basic flow -> This runs the ever-so slightly more complex I think the issue is that when using one specific Catalogue item does meet the criteria on the branch And as a result it runs the no match path. As a result, it looks like the ticket is logged using the correct PCF (because I prompt for the same things in the same order) but it isn't. As a result, when the BMP runs, it is looking for a variable from a custom form that hasn't been used and it changes the priority. By changing the order of the No Match tasks, I have confirmed that my tickets are getting logged using this path and not the correct path via the switch capture. Thanks James
James Ainsworth Posted January 11, 2021 Posted January 11, 2021 Hi James, I was just curious if you managed to track down the correct paths for your Progressive Captures and see where they might be going in the wrong direction?
Steve Giller Posted January 11, 2021 Posted January 11, 2021 What setting do you have for servicemanager.progressiveCapture.servicedetails.catalogRequired? If that is OFF the branch would be correctly taking the No Match route if a Service but no CI was selected.
James Gallally Posted January 12, 2021 Author Posted January 12, 2021 Thanks @Steve Giller, I have just checked and it is currently set to ON, should I change it to off? Thanks
Steve Giller Posted January 12, 2021 Posted January 12, 2021 @James GallallyNo, if it's on then you must choose a CI, so that's ruled out customers not selecting a CI as a cause.
Recommended Posts
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now