Berto2002

@Steve Giller maybe JJack has a different question but mine is: In the example you showed the screenshot of, if I deactivate v10 (so we have no Active Version of that Workflow at all), will Requests with prior versions (1-9 in this case) continue to run uninterrupted? I seem to recall about 2 years ago, when I first started, I did exactly this on a Change BPM (It ran into an error publishing as it had too many versions - an issue you've since fixed) and all my inflight Change Requests with previous versions stopped working so I had to re-activate the BPM and leave it. I am after confirmation that issue was rectified.

I want my Full Users to be able to see certain FAQs on all Services (but not Basic Users in the portals). FAQ have a visibility of Portals, Service Desk or Both. Sure, if I select Service Desk, it's not showing on the portal and it does show against a Request for that Service as a "Solution"... But is there anywhere a Full User can look-up the FAQ on any given Service if they do not have Services Manager access to view the Service Portfolio and don't have an open Request in front of them?

It would be nice to hear a definitive answer to the second question since I am scared to disable an old version of a workflow for fear of it stopping all instances of that workflow in flight (even though different versions)

As admins I am always interested in the contents of the Request data fields and their extended fields. I have set-up a custom button that runs an Autotask that emails them to me; but it would be much simpler and a great support to all admin people if we saw a button next to every Request that gave us an instant view of those fields for diagnostics; either a pop-up like the Activities box or a new tab thing. it would be a great time saver for all admins in testing and troubleshooting. How about a button here next to the other 'admin' type button:

Thanks, I understand several customers have reported this issue to Premier Support. I also confirm that when we had the Human Task as the last update, the Change Type was populated OK and the new Request ID was correctly published to the Timeline so all 3 of my symptoms had the same cause.

@Emily Patrick, @samwoo I believe this is what I asked for here. If that works for you, please support. We also want to move away from emails but the HB tool is highly engineered around emails if you don't choose to rely on it's inbuilt notifs prefs. I mentioned an example of JIRA where you can have the timeline element of a JIRA ticket provided by another messaging platform like Teams; that's what we want; to replace the whole timeline in Requests with our preferred collaboration platform MS Teams. I have started this by allowing our people to receive their new Request and Resolution notifs by Teams instead of email thus: Users opt-in to teams notifs: Workflow updates custom fields on user's profile: Then at start of the workflow we look at the user's profile and determine if we send them an MS Teams private message or an email: The disadvantage of this approach is that you have to put that bit in every Workflow... We only did this as a test to see if it worked (it does) but we would also need to have nodes that update this in Azure Active Directory so the daily user import doesn't over-write our custom fields.

We experience a row limit of 25,000 records but in such cases, we do get 25,000 rows downloaded which is a truncated subset of the full results; we do not get zero results as you show here. So looks like another issue with your extract.

@JJack see if the one that failed meets the conditions we describe in this thread. You may be experiencing another facet of a potential defect introduced earlier this week with the release ("A ticket was raised, but not associated with the process").

I confirm that adding-in a Human Task just before the create step led to the spawned Request 'picking-up' the prescribed workflow. Thus, the issue appears as you have described @Paul Chambers. For us it is impeding a new development; for you an existing process. Good work, thanks for contributing. I have a workaround to add something to my Outlook calendar to attend to this Human Task once a month but not ideal...

@Paul Chambers interesting. Are you also seeing this issue? Do you have any idea as to whether that was an intentional 'change' or a consequential 'change'? That does indeed match my circumstance because my SR is untouched by humans; it's purpose is to overcome the limitation that Routing Rule Templates can't open CRs so I need an intermediary to spin one up.... This is the timeline of my SR: So I am now going to put a Human Task in there and see if it 'picks up'...

I recreated the nodes from within than workflow and still no workflow is picked-up so that rules-out in issue with the template copy.

@James Ainsworth. Good question. I ran the report for this and no, we don't. The report is all services, cat items and subscribers so each cat item has multiple lines for each subscriber. In alphabetical order on cat item only the one in question shows. Today, I had a thought that the nodes that do this work were pasted (via templates) from another flow and then adjusted (in case you noticed, this is why the Result Reference is "logRequestServiceRequestTest" (not, presumably "logRequestChangeRequestTest") but I assume the value in result ref is incidental as long as it is consistently referred to.

We have noticed Requests are not (always) dynamically refreshing in the browser after completing an Activity Analysts used to wait just a few seconds after completing an Activity and would see Timeline updates that result and would then see the next Activity pop-up. Now they are often not seeing this happen and are having to refresh the browser tab to see the updates. I noticed this myself today, asked around and I am getting this feedback. Not only is this inconvenient and slowing them down but will be increasing load on HB servers. Anyone else getting this please? Of note, perhaps is we had SM release go out on Tuesday: 2.156.0 (2970) 07-11-2023 05:31. This does seem to coincide.

This has been in place since our implementation nearly 3 years ago. It seems to work but not sure if any element could do with improvement...

HB have found this is a defect and is logged as KE00179871 (Not changing customer when using the Change Customer node if Request is raised by a Basic USER). I have not seen it appear on the Published Defects list so assume it's planned to be in a forthcoming release at some point. @LawesD @Kelvin @SJEaton

I think Miro found something when I sent an ICF so we may see something to fix this in future. However, it's not a biggie for sure.

@Andrew Parsons New Bing (ChatGPT) is amazing for writing Regex. Just make sure you have the "More Precise" option and that your words are the full requirement. Having said that, we've been using this Regex for years: (?<=\()(.*?)(?=\)) This is not looking for the email address, it's looking for whatever is between a set of brackets. This is much easier and reliable because we control the input (i.e. the email we receive from another system) This is our subject: "Single HR Leaver (firstNamelastName@domain.gov.uk) - 20231031" The beauty of the above is also that it extracts whatever is in the brackets and our upstream system puts "noEmailDefined" in that space if we have no record of an email; so then I can filter those out in Workflow and do something else with them.

@Gareth Noon I think the reason you're stuck is that you're using sub-status. "Waiting Customer" is for if you are asking questions etc during the lifecycle, not asking them if you can close it. If you think you have done the work, resolve the Request and then put in a Suspend node which is waiting for status change with an expiry of 30 days. If the customer goes to the portal and updates the Request, it gets set to Open (status change) and this is selected by the subsequent decision to come back to your team. If not, it closes. The short answer is that you need the suspend nodes with expiry. You can use this to follow the expiry of a Waiting Customer node but why not just resolve it?

Can anyone help with this mystery, please? Because we can't log a CR from Routing Rule Templates, I intend to log a SR and have an SR Workflow create a CR and then close. It nearly works; I get the CR but we have 3 important issues. I want to rule out my oversight first, then ask if there is something specifically blocking SRs raising CRs; before moving on to suggesting a defect. First issue is that the new CR is not picking-up the Workflow. Create node is this: The Service Catalog item under Change for Network & Infrastructure Support is: And that Workflow is active: The CR gets created but has no Workflow: I first tried under ServiceDesk Basic User (a Subscriber to the Service) and got the error. I than tried as me (Full User) and full subscriber and still got the error so ruled-out the user being the issue: Interesting Observations: The "Raised By" is THIS: which is this when clicked: Second issue is that the node that is in workflow to update the timeline with the new requestID (as diagnostics) is reporting no value, despite the "outcome" variable reporting success (so the overall flowcode reference works to refer to the node that spawned the CR): The node to update the timeline has this config and the red and green match the above (but for the last bit obvs): And the node that creates the CR has the following outcomes which match the above: The Third issue is that, despite the node to create the Change Request stating to set the CR type to "Standard" (see first screenshot), the spawned CR has no Change Type set: Of course, I need workflow and I need a Change Type for this to work. Any ideas please? Thanks in advance.

I will refrain from using the word 'easy' in future; but in this context the requirement should be seen as 'easy' as it's well-established and in use where shown.

At present, Routing Rule Templates cannot raise Change Requests. Use-case: due to the fact I cannot use Service Manager to schedule to log Requests on the 2nd Tuesday of the month (see other post asking for new scheduling options to allow this), I planned to use a trigger from an external script - where we can detect such variable dates - to send in an email which would be picked-up by inbound routing rules and pushed to the routing rule template to log a patching change request for Microsoft servers. But I find no option to log a Change Request. As a workaround I need to log a Service Request into a mini Workflow which then logs the Change Request and closes itself down. Can't see why there shouldn't be an option to log a Change Request from a Routing Rule Template so requesting it please.

Microsoft release Windows Updates (usually) on 2nd Tuesday of the month. There's no way to schedule this kind of recurrence in the Service Manager tool; we can only set specific numbered days of the month. As most people will be running Windows and many organisations use similar scheduling cycles for all sorts of reasons, I would like to suggest HB enhance the scheduling system (as used in Scheduled Requests and Reports) so we can specify such dates. The standard for this is in Outlook and should be easy to replicate: Use case: allow us to align the production of reports or scheduling of requests to organisation-based deadlines using the same facilities.

@Miro I have sent you another ICF form in which we are having this issue also. It completes fields as it goes but then stops and only populates the last 4 in the summary box when the very last ICF field is entered.

Hi Steve. I'm referring to Tuesday morning on our 'install date'. However, we will monitor this over the next few days. We definitely had one such case on Weds.

But before today (i.e. before the release), comments from the Customer would have taken the Request off hold. Anyone else seen this?