Steve Giller

In that case use true as the boolean without any quotes and all lower case. True or "True" are not boolean values

The error suggests that there is a 'T' where it's expecting something else. I would begin by checking that the JSON is valid with an online validator, and then ensuring that all text values are enclosed in quotes.

There are 8 custom fields for a User (Attribute1-8 in the dropdown) which you can rename using translations and store additional information (such as Cost Centre) in.

I'm not sure what's being asked for here, are you talking about the right panel within Intelligent Capture? If so, exactly what information are you hoping to see there? It would not be possible to inform the person that there are missing elements in the Capture, however this should be possible from within the Business Process by using a Get Customer Details node, checking the elements you want to ensure are populated, and sending an email to the relevant User.

@Salma Sarwar External Authorisations can only be sent to a single Authoriser. If you need to send to multiple Authorisers, or use the enhanced features such as weighting, please consider Authorisations. These are detailed on the Approving, Scheduling, and Implementing Changes wiki page

Unfortunately ... that's what you'll need to do.

I've tagged this as an Enhancement for you

a) No, not in the Activities view. b) You could probably create a report for this. c) No, I'm not good enough at reporting to write that for you

Sorry - missed the obvious - "% - ELS" would have worked. LIKE without a % is the same as =

I've tagged this as an Enhancement for you.

On Hold means the SLA is paused - otherwise it's not on hold! I think you're looking for an Active Sub-status that has an expiry time - the trick there would be to know what Status/Sub-status it reverts to once the Third Party Sub-status has expired.

Looking at the data from Direct Database, you can use "% ELS" to avoid that. Yes, but without picking apart the data and the report I wouldn't be able to say for certain, possibly the - is a modifier in MariaDb, or the - in the data is not a simple dash (e.g. an em-dash) etc.

The instructions for this are on the Managing Request Catalog Visibility wiki page.

is not the same as If you update your filters to match your WHERE clause you should see the same results.

@JakeCarter Can we clarify which area of the product you're asking about here - this looks more like the Employee Portal than the Customer Portal to me.

As far as I'm aware there are no plans to implement this kind of solution.

@Paul Morrow I would also advise upgrading to version 3.12.1 which contains a minor but important bug fix.

@Berto2002Wrong Steve G, but I'll pass it on!

@Dan MunnsThis is really a discussion for the developers to have, however the above still wouldn't work - if you design a "Global" custom button for Incidents how can you be sure that it would apply to all Incidents? Would Facilities want to see it, or Human Resources or Payroll? Even within a Service it might well be appropriate for most but not all CIs Already we've narrowed the scope from "Global" to "Per Request Type" so it's not really a straightforward or even clearly defined suggestion at this stage.

Glad that's working, thanks for letting us know.

It can, but it wouldn't make much sense to do so. It would be much better to summarise the content into a new, single post that has a clear requirement rather than retroactively tagging a conversation and having to pick through to establish what's wanted.

(Moved to the Service Manager forum where the relevant Team(s) will have visibility.)

I've tagged this as an enhancement for you.

The first step would be to post the Task Outcome to the Timeline and ensure it's producing a valid value for the Priority: The outcome needs to be a Priority ID, which may or may not be the same as the Priority Name.

Your Decision Branch is set to use details from a node with the Result Reference set to "fcres" but your Get Request Details node has a blank Result Reference. You will need to give your Get Request Details node a unique Result Reference and then rebuild the expression on the branch. It is recommended to give all Get Request Details a unique Display value (in this case, I would suggest "Get Request Details for Closure") to make selecting the correct variable easier, and Result Reference value (e.g. "closeDetails") to ensure that the values are not overwritten by another Get Request Details node.