Victor

Yes. The main purpose for this limiting is when searching for users/contacts in the UI in form fields (which is what the checkbox does, users).

@Met yes, it's hardcoded at 10.

@will.good so what is requested here is basically a report... which we have as functionality. I'll expand on this: I do understand that DB queries give far more options and flexibility in terms of filters and such but at the same time DB queries are gated behind SQL knowledge and knowledge about our data model and structure which not every user has and is certainly not something we would require from any user. Also, it is always a possibility that a specific query is poorly constructed causing issues for an instance. For these reasons, we will not expand Direct DB beyond what it is now. My advice here is that if the current reporting engine does not allow you to build a report that returns the results that a certain query returns, then request the reporting functionality to be enhanced.

@Berto2002 there is no inherent exclusion of the System Internal Context updates. These entries, for some reason, are not matching the criteria in the filter, i.e. the published date for these is not > StartOfYear or they don't have that Target ID (might be that these entries do not have a published date value, possibly...)

@Berto2002 what is the report filter? What criteria are you using there?

Based on the screenshot, the challenge here is that the workflow is not actually in a Failed state but is also not in a "true" Suspend state (the node there is not a Suspend type node) so Restart and probably Resume will not work here. I have seen this before where the workflow can get into this strange state of neither failed nor suspended and it cannot be "restarted" by normal means. If none of these suggestions here work, raise an Expert Service request and we'll have a look to see if we can resume it.

@Jim as far as I am aware this thread (as with any thread on our forums) is posted on our internal workspaces where product managers and developers review them. As if and how it will be implemented, I cannot say. Perhaps something you can discuss with Customer Success if it is a subject of interest.

@Jim I understand why/how the term Archived can be read as you did, however, in this context, Archived represents what is the asset status in your (physical) inventory not what is the asset as a record in the Hornbill database. You can perform a data cleanup at any given time according to your needs. Steve advised of its primary purpose and what is mostly used for, but is not limited to just removing test data. Depends on how many asset records you have in Hornbill. But I would say, storage for asset data alone only becomes noticeable when we talk of numbers in the hundreds of thousands possibly even more. Usually, most storage consumption in an instance is attachments and data for active running workflows/BPs.

@Jim it has indeed... As much as we would like to have everything fixed at once, we (by we I mean development) do need to prioritise work so they work with a priority list. Sadly, this defect did not make it high enough on the list yet...

@CraigP questions are for the values of questions and answers, questionsFieldMap is for any mappings that you have for answers (the answers mapped to request fields). If you are simply looking to have a set of questions and answers on a request then this thread can be useful: For example below is a payload to raise an Incident with Summary: Test Summary Description: Test Description No customer (if a customer is required then <customerId> and <customerType> would have to be set) Service: 666 (this is the ID of the service of the request, needs to be a value for a service in your instance) Questions: Field 1 (type Text): 123 Field 2 (type Textarea): 456 <methodCall service="apps/com.hornbill.servicemanager/Incidents" method="logIncident"> <params> <summary>Test Summary</summary> <description>Test Description</description> <requestType>Incident</requestType> <customerId/> <customerType>0</customerType> <serviceId>666</serviceId> <questions>[{"form_id":"form_1","question":"Field 1","question_id":"field_1","answer":"123","answer_value":"123","field_type":"text","entity_type":"request","hbfield":{"question":"Field 1","field":{"id":"field_1","defLabel":"Field 1","transLabel":"x","binding":"global.form_1.field_1","noInvisibleValue":false,"design":{"isVisible":true,"isMandatory":false,"isReadOnly":false,"showIfEmpty":false,"extraClass":" "},"control":{"type":"text"},"uid":""},"value":"123"}},{"form_id":"form_1","question":"Field 2","question_id":"field_2","answer":"456","answer_value":"456","field_type":"textarea","entity_type":"request","hbfield":{"question":"Field 2","field":{"id":"field_2","defLabel":"Field 2","transLabel":"x","binding":"global.form_1.field_2","noInvisibleValue":false,"design":{"isVisible":true,"isMandatory":false,"isReadOnly":false,"showIfEmpty":false,"extraClass":" "},"control":{"type":"textarea"},"uid":""},"value":"456"}}]</questions> </params> </methodCall> It is a simple question capture but it should give you some guidance on how the JSON string would need to look for adding questions on requests. Please be mindful that the payload can differ if we have things like translations or some very specific capture configuration that you want to mimic in the payload (which are actually not relevant for the API, this is mostly for how the capture works when the user inputs data in UI). I will put the expert service request on hold until you have a chance to review this. If you still have any further queries and/or need assistance with this I will allocate the expert service request to one of our tech specialists and they will progress this forward.

@Jim this is a know issue/defect: KE00167283

@Adith To confirm, updating the sub-status does exactly what the term says: update the sub-status and nothing else apart from this value (assuming the update is configured as such).

@Jim this is an oversight on our part. That documentation should be retired, the templates were a feature we thought of having back in the early days however, since then it was rendered obsolete by progressive and intelligent capture mechanisms. Request Templates have been deprecated and retired and no longer exist in customer instances. You can use intelligent captures to achieve what the templates would have provided.

Just some more information as to how that was the cause in case anyone else reads through this in the future. The problems that were missing the timer were not using the intended workflow, they were using a different one based on the value set on app.requests.defaultBPMProcess.problem. That workflow did not contain the Start Timer nodes or they were not in a position in the workflow that trigger the SLM evaluation. As a side note, the app setting mentioned here comes into play when the service does not have a workflow configured for Problem request types.

@billster if you click on the SLA, where it says "UK SLA ITSM09005 Minimal", you should get a popup open up that has these options: If you then click on "Show Diagnostics", is there anything in the diagnostics log?

This thread is not related to forum functionality. Moving it to the relevant product section @layla.javady FYI

@billster then probably there is some configuration missing somewhere... you said the SLA is set and not the SL so I would check the rules for service level if the criteria set there is matching the request data for the problem request that you are raising (e.g. if the criteria in rules is Priority = X then ensure the problem request has a priority and is the priority X when the SLM triggers, etc.)

@billster and did you have timers working for Problems before or this is a new setup you have put in place?

@billster it might be this... For some reason, some customers are still affected by this issue, even if the fix was deployed yesterday. Do you have the SLA/SL/Timers working on other request types or just Problem requests have this issue?

@billster do you have SLA/SL configured for Problem requests? And do have the Start Timer nodes in the workflow/BP for the Problem requests? The timers on any request type follow the standard SLM configuration. If you have timers working for other request types you would need to have the same configuration in place for Problem requests. https://wiki.hornbill.com/index.php?title=Service_Level_Agreements https://wiki.hornbill.com/index.php?title=Structure_Service_Level_Management

@CraigP I am sorry but we have never supported this approach in workflow node configurations. The node and variables are to be used as they are. Sure, with sufficient technical information, one can venture and do some advanced things like this but again, this would be outside what the functionality was designed for and thus not supported.

@Daniel Ali also for future reference, there is always a possibility that your question or query has been raised before so we recommend doing a quick search. Here are some examples where the issue you reported has already been discussed. Hope it helps.

@Daniel Ali for future reference: I have now moved this thread to the relevant section of the Hornbill product.

@Cigdem Turner for future reference please use the relevant section on forums. I have now moved this thread to SM product section.

@Llyr as the message says, either you do not have access to the mailbox where the email resides or the email has since been deleted from the system (mailbox).