Victor

@Archana create a custom role as follows: Details: System Rights: Assign this role to the user that does the import and try the import again.

@Berto2002 indeed, by looking at the UI it is made to look simple to be used by any user. However, as it is often, the simple things that a user can see and make use of in the UI have a quite complex mechanism underneath. So even if at face value it might not seem like something difficult to implement or develop, it is possible that actually it requires quite a few things to be created and/or changed. I am saying this because I don't want anyone to have an incorrect expectation when it comes to such things, we would not want anyone to think and expect that A, B or C is easily achievable without getting this confirmation from us.

@Martyn Houghton sorry, I am not aware of the timescales, but I have asked development to provide some or to add this back to the roadmap...

Unable to run Query [getUserAccountsList] You need the right 'sys.a.manageUsers' in order to invoke the query: getUserAccountsList Have a look if your user has the "Hornbill Service Manager Integrations" role.

^ This

@RichardD assuming the email address is unique for each customer (which should be I would think) then you can (also) use entityBrowseRecords2 to also retrieve the customer ID - the list of records should only contain one record here.

@RichardD for retrieving the list or requests I recommend https://api.hornbill.com/data/?op=entityBrowseRecords2. I assume you have the customer email address and we want to use that to get the customer/userID to filter the requests?

@RichardD sorry to be a pain, but what do you need the customer open calls/requests for? Reporting? Something else?

@RichardD why are you using this, and for what purpose? I can tell you already that it won't give you what you are after, regardless of what you are after, since this is specifically and solely used by routing rule operations. However, we might be able to suggest a more appropriate API if we know what the objective is....

@lomixture when is the Site set on the request? Is it right before the Get Request Details? Further before? Captured during IC? Also worth checking on the example request that went through the "No Match" if indeed there was that site, specifically if that site Code is the one shown in the condition...

@Martyn Houghton well, in theory, there is no technical reason why not having it back on the roadmap. But knowing this is actively ironed out, I would say there is perhaps little value in adding it to the roadmap since we should expect this in the next SM update or so...

@billster I have edited my reply above, looks like an incorrect expression.

@billster first thing I would check is the rule order... have a look if the email is not actually processed by another rule that is higher in the order list... EDIT: actually, looking again at what you tried, looks like an incorrect expression. You need subject NOT LIKE '%phish alerts%' ... so you enclose the whole criteria with quotes, including %

@chriscorcoran

Not a forum thread. Moved from Home - About the Forum - Suggestions and Feedback to the relevant section.

No, I don't know this I'm afraid. All the info I have about new features is what is also made public in the Roadmap, which is what you also have...

I can but there is little value in doing this since it has been exposed already... No, it can't. You need dynamic or runtime values here and this concept does not exist in the API scheduler. You can achieve this with a custom solution but someone would have to develop this solution (script/program/etc.)

@will.good yep, that is correct. Welcome to the wonderful world of logical operators ... Well, I say wonderful...

@Berto2002 so using the API scheduler, which, yes, has a JSON config file. I thought you were invoking the APIs using your own tools/scripts/program. Using the API scheduler you won't be able to do the scheduling since you need the request reference as an input param and this needs to go in the config file.... unless you manually add this in the config file, for each request raised, which negates the automation completely... Also, you need a new API ky assuming the one you posted above is a valid one...

@will.good Does this help?

@Berto2002 first, JSON? Not yet supported...might work...might not... second, you can only have a payload using the available parameters listed on https://api.hornbill.com/apps/com.hornbill.servicemanager/ChangeRequests?op=logChangeRequest. If there are no params for schedule data (there are none) then no, you can't append this data as the API will fail since you are sending data the API does not know about. So you need to have the request raised, then use the schedule.

@HHH decision nodes whereby you check if the field from IC has a value... e.g. field X has value? :: if Yes, do what needs to be done and continue workflow; if No, field Y has value? :: if Yes, idem as for X; if No, field Z has value? and so forth...

My OCD looking at all the nodes... not arranged in a line... and all connectors not being a straight line ... and intersecting each other...

@Mark (ESC) no, you're not missing anything... EDIT: also, is not you...

@Mark Priest