Victor

@Osman as I explained above, based on my current understanding of how this is designed to work, the suspended workflows end up suspended indefinitely due to a workflow/request setup misconfiguration. If you believe the configuration is correct but for some (unknown) reason the workflow does not behave as designed or some other functionality does not work as intended (e.g. override locked actions), please use the advertised channels to raise a support request with our team for further investigation (https://www.hornbill.com/support/)

@Berto2002 time is irrelevant in this scenario. We are only talking about the date here.

@Marius thanks for the additional info however what I said above is still valid. It is very possible (I would say with certainty) that the workflow that runs for these requests is not reaching the stop timer node in this scenario, therefore the timer is not stopped. I have no idea how the workflow is configured but I would say have a look at the configuration, in the specific context that you have for these requests, and see if and how the workflow is not reaching the stop timer node(*) (*) this assumes that your request has a workflow that runs and this workflow has a stop response timer node I realised that I forgot to explain how workflows and timers interact above so I have edited my above reply.

@Marius this is a red herring. The aspect of the customer and owner being the same person has nothing to do with request timers. Most likely either something working incorrectly in the SLM/BP engines (in which case you would see this on all requests not just that subset) and/or the workflow(*) is not set correctly to mark the timer. I would start by looking at the workflow to make sure that the relevant nodes (Mark response Timer) are in place for timer to stop. EDIT: (*)the workflow is solely responsible for stopping timers on requests, specifically response timers for which there is no other mechanism for this timer to be stopped

@QEHNick the banner promotes the Hornbill event we hold every year for our customers. It does not promote external products (e.g. Go Pro). I understand my colleagues from Customer Success have been in touch with you to discuss any queries and concerns you have on this matter.

@Jim interesting and this is definitely a first ... While I do not want to temper the enthusiasm here, it would be good to see what APIs you make use of in this tool. Our API documentation is not really geared for this type of development (we have a new, better one being developed but this is WIP). It can be used, of course, but unless one is familiar with some underlying aspects of how HB works then is not very straightforward to make use of APIs in this way. The reason why I am asking about APIs is that we would need to ensure we don't end up with "broken" data, which would look ok on paper but in fact, is not entirely correct. For example, if your tool is making use of application APIs (e.g. com.hornbill.servicemanager::Asset/updateAsset2) then we should be ok (in theory) but if you use data APIs (e.g. data::entityUpdateRecord or data::updateRecord) then it can be a bit problematic as they work in a certain way (update one or a set of records in a specific table) and more would need to be done in terms of updating data to ensure related data, for example, are also catered for. If you use, for example, data::entityUpdateRecord for the assets table (and only this), your asset will look ok when you look at it in the asset UI but it might be broken in other areas because the asset related data is missing. On GitHub we have an asset import (and update) tool: https://github.com/hornbill/goDBAssetImport which can be used as a reference to see how we do the create and update of assets. It is possible you already looked at this but if not, it would be a good idea to have a look a the code.

@Stuart Torres-Catmur Does this help? https://wiki.hornbill.com/index.php?title=How_to_configure_OAuth2_Authentication_for_Microsoft_Office_365_Mailbox_integration and then https://wiki.hornbill.com/index.php?title=How_would_the_Office365_administrator_approve_permission_requests

@Jeremy what do you mean by "makes it easier to manage autorisations"? Manage them in what way?

@Berto2002 the date/time values here need to be in ISO 8601 format. Durations in this format define the amount of intervening time in a time interval and are represented by the format P[n]Y[n]M[n]DT[n]H[n]M[n]S or P[n]W. In these representations, the [n] is replaced by the value for each of the date and time elements that follow the [n]. Leading zeros are not required. The capital letters P, Y, M, W, D, T, H, M, and S are designators for each of the date and time elements and are not replaced. P is the duration designator (for period) placed at the start of the duration representation. Y is the year designator that follows the value for the number of calendar years. M is the month designator that follows the value for the number of calendar months. W is the week designator that follows the value for the number of weeks. D is the day designator that follows the value for the number of calendar days. T is the time designator that precedes the time components of the representation. H is the hour designator that follows the value for the number of hours. M is the minute designator that follows the value for the number of minutes. S is the second designator that follows the value for the number of seconds. For example, "P3Y6M4DT12H30M5S" represents a duration of "three years, six months, four days, twelve hours, thirty minutes, and five seconds"

@Adrian Simpkins so thanks to @Steve Giller investigation I can now confirm that my above statement is, let's say, somewhat incomplete So an archive user cannot login when using direct login. It seems this restriction is not enforced when a user authenticates with SSO. Something dev team is looking into.

@Amanda Durgan the error you see reported there comes from Microsoft. If anything changed, it would be in Azure configuration (your environment). The ITOM build deployed earlier has nothing to do with SSO code.

@DRiley SM Knowledge Manager. The other one is not yet in use.

@Adrian Simpkins an archived user cannot log in. Is it possible that it is actually a different user there? Perhaps very similar to the archived one? If not please raise a support request so this can be investigated.

@DRiley no idea if is due to image size, could be, but based on your above comment, it might not. Afaik we don't specifically document a certain set of image types that we support which means we don't restrict any... I think perhaps we can make use of a support request to see if we can get a better understanding of how that happens (I have tried several images in my instance, to see if I can investigate this further there, but I don't encounter this issue)

@Berto2002 can you post the full payload? EDIT: obv, obfuscate any personal/sensitive data

@DRiley does it happen with other format types or just SVGs?

@Emily Patrick I'm afraid not. The bulk actions are not customisable.

@Salma Sarwar we don't have functionality for that in Hornbill...

@Mark (ESC) if you are using service domains, and the widget is on a page for a service domain, all requests in the widget will be from services that belong to that service domain. It will not display requests for services that belong to other service domains nor requests for services that belong to no service domain...

This is not about the community forums so I will move it to the relevant section for product suggestions

@lomixture what is the username you wish to change to?

@Adrian Simpkins rules-based workflow, that allows the creation of simple workflows based on business rules and actions. One of the significant benefits to users is it will be possible to use these rules to decide at what point (if any) workflow is triggered, instead of requiring a workflow to be triggered at the point of raising a request.

When configuring SLA response and resolution targets and expiry times on certain BP nodes you might find the target being set differently than possibly expected. This is because a common oversight as these timers needs to be expressed in SLC (Service Level Calendar) times or working hours or business hours (which are usually X hours/day) rather than calendar time (which is 24 hrs/day). When configuring a target time of N days, the value needed to be set would be N working days rather than N calendar days. The value that needs to be set will be obtained by multiplying N with the number of working or business hours/day. We advise to always configure hours (rather than days) as it is easier to figure out the values required to be configured for SLA targets or expiry times on business process nodes. However, in certain areas (e.g. SLA timers), depending on the target, it might not be always possible to use hours exclusively. Below is a quick example of how to find out which values needs to be configured depending on the intended target: Let's say we need to configure a resolution time (or an expiry time) of 5 days. We need the target to be set in 5 days from now. Let's also say the working hours are 7.5 hours/day although this really depends on your SLC. Step 1 is to find out the number of working hours equal to the 5 days we need to set: 5 days * 7.5 hrs/day = 37.5 hours. You need to configure round values therefore if you don't have a round number of hours you also need minutes (seconds, etc.). The 37.5 hours equates to 37 hrs and 30 min. In conclusion, for a 5 day target, the configuration needs to be 37 hrs and 30 min. As mentioned above, for simplicity always use hours if possible. If you need to configure this value as days/hours/min then the 37.5 hours need to be divided by 24 (which is the number of calendar hours in a day) resulting in 37.5 / 24 = 1.56 days. The 1.56 days equates to 1 day and 13.50 hours. This further equates to 1 day 13 hours and 30 min. In conclusion: 5 day target in the context of 7.5 working hours/day is set as: 37 hours and 30 minutes or 1 day 13 hours and 30 min If you don't want to be bothered with the mathematical calculation, you can use this Excel sheet to find out what values you need to configure. Type in the desired target time and the number of working hours per day. The values you need to configure are in red: Hornbill_Timer_Targets.xlsx IMPORTANT: the above only applies when configuring expiry times on Service Manager workflow nodes. Non-application nodes, such as human tasks or external authorisations, do not account for Working Time Calendar, and as such the above setup does not apply in this scenario.

@Berto2002 it does not (if by any chance it does, it shouldn't, so it would be a defect). The Hornbill admin account is not counted against the number of subscribed licenses. It will appear in the list, because it is in essence a user in a Hornbill instance, but it is not counted against the subscription.

@Sam P you can perhaps dedicate just one custom filed to this (instead of several)? Then update this field with different values as the workflow progresses...