Steve Giller

Not something I'm familiar with, but is your Attendees parameter correct? On the Microsoft documentation it looks like it's in this format: [{emailAddress: {address: 'adelev@contoso.com',name: 'Adele Vance'},type: 'required'}] which looks different to your node.

If the emails have consistent content in the fromAddress, Subject, or Body, you can catch that with an Inbound Routing Rule. Hornbill is also not an answering service, so if you want to respond to the sender you will need to automatically raise a "silent" request, with a Workflow that emails the sender with the required response and then closes itself. The benefit of a Request is that you can (by using Categories or specific Summaries etc.) report on this and know how many of these you are automatically fielding - and even find repeat offenders if required!

@Damien Lynn In extremely generic terms, "Something is broken" will be an Incident, and "I need something" will be a Service Request, so if you can have a generic one for each and word them suitably for your end users, you should all but rule out the need to swap from SR to IN or vice versa.

I believe that ui.app.com.hornbill.servicemanager.operation.popup.values is the setting you need here. Please be aware that this is a global setting and applies to all manual updates.

How do you decide whether an email is required?

As far as I'm aware "Security Error: 1" indicates that the system is unable to verify the session. Unfortunately this is always a generic message to avoid exposing security information. This could be as simple as a very brief connection drop preventing your session being authenticated for that transaction, so I think the best course of action would be to trap that error and re-present the data when the call returns a failure with this error (ensuring that this does not create a loop, of course.)

The date range selector has been available for some time now.

This would be done by the Auto Responder, and applied to the Request as an update. The Workflow would then come off hold and you could react to the content of the update.

MSSQL is not my forte, but I'd start by simply removing the semicolon terminator from your statement. Each Asset class adds its own "AND" clause to ensure only the right types are returned, so assuming the SQL is parsing the semicolon as the end of the statement, and then there's an additional "AND" clause that fits the error you're seeing.

If you're using the Auto Responder to update Requests from email, you can put the Request on hold, configure the Service to select an "Open" substatus on update, and use a Suspend -> Wait for Off Hold node to respond to the incoming email. This does not prevent another action taking the Request off hold and triggering the Workflow to move on, however.

@Estie This has been fixed and will be in the next Core UI release. I can see this working on my test Instance so when that build completes the testing cycle successfully and is released to Live you will see the changes.

They would need a collaboration license, yes. If they're not accessing any applications that would be all that was required.

If this is for External Authorisations it is not possible to edit the Template. You would need to use full Authorisations for that.

Have you tried inserting that into the Details of the Authorisation Task?

You could simply not post it?

Have you tried using the "__clear__" value to empty the field?

The "customer" account is a System account that manages the Customer Portal - this is not an account that can be directly interacted with and will always have an open session while there is any activity on the Customer Portal - even if this is just that someone has accessed the login screen, for example.

I'd suggest: Get the data for "customerGet" Post that to the Timeline Get the date for "analystGet" Post both results to the Timeline That will at least confirm what you're getting from the "customerGet" and whether it's overwritten by the "analystGet"

Oh, right, I get you, so: What does that mean?

The variable displayed in your screenshot is from a node with e Result Reference of getRequestInformation, which is the default value for a Get Request Information -> Request Details node. I don't know where it's getting the data from, but it's not coming from either of your Get User Details nodes.

Development are looking at this and we hope to have an update soon. In the meantime the button itself simply replicates the action of the browser's own back button, so the workaround is to use that.

That would be "d/m/Y" I believe. https://www.php.net/manual/en/datetime.format.php

Without looking this is guesswork, but I would imagine the Workflow that the Request uses has an Assign node using the Round Robin option. I would suggest having a decision before this node (don't forget to ensure the information is up to date with a Get Request Details node where necessary) and if the Request has an Owner, bypass the Assignment node.

Just click on the currently Active version in the Publishing flyout:

Is the scheduled task running in the context of your Windows account?