Search the Community

Is there any way to set an expiry period for a duration of 30 seconds? Im trying to find a workaround in a BPM whereby an analyst has a window of 30 seconds to add an asset to the call and putting decimals in the minute field doesn't seem to do the trick. Ideally I would like a function that suspends the flow until the analyst adds an asset, marking off a stage checkpoint in the process. At present there is no function I can find that will automatically continue a workflow after an asset has been added by the analyst and mark a stage checkpoint, in the same way as if you suspend a node until a linked service is added for example. My workaround would present the add asset screen and, after 30 seconds, continue the workflow regardless. One minute, the current available minimum expiry period is too long to wait for the workflow to tick over to the next stage. .

When creating an API key with an expiry you select a date, for example the 23rd June 2019, but the expiry date gets set to the previous day at 01:00hrs. I suspect there may be a bug with the timezone calculation, as you would expect the expiry to be 00:00hrs on the 23/06/2019 or even 23:59hrs on the 23/06/2019. Can this be looked at please. Cheers Martyn

In our Incident process we have automatic assignemt to a team and then a "Suspend, wait for request owner" node where the analyst in charge of the "Inbox" manually assigns tickets to an analyst depending on product and availability. Is there a way to set a timer on the suspend node so that if a request has not been assigned to an owner for a set period of time, a manager is notified?

Related to my post below, it would be useful to be able to specify a specific time as a well as date for the expiry of an API Key. Cheers Martyn

Hi, After been running live now for a couple of weeks I have noticed that we have an awful lot of requests still sat in a 'Resolved' state despite them being resolved for more than 5 days. In our BPMs we have the following logic... The logic in the 'Suspend wait for status change node' is as follows... Should I have a 'Get Request Information - Request Details' node between the 'Suspend' node and the 'Decision' node? The logic on the 'north-bound' arm of the 'Decision' node is... The build of this part of the BPM was lifted directly from a sample BPM provided to us by during our 'Switch-On' which looks identical to the logic in the Example BPMs. Is anyone else having problems with their requests not auto closing after the expire period time? Thanks Steve.

Hello, Currently having an issue with the lifespan setting discontinuing the custom field 21 variable in the expiry field. This seems to accept the setting when saving, but every time it is saved and you re enter the BPM the setting appears blank. I am using the global input for custom field 21 rather than the specific form field, as there are different form routes from the pro cap that use this field and converge on this point of the human task. I believe the fact it is not retaining the information is why the process in practice is not working, as the human task does not expire based on the date/time of the custom field. Has anybody got any advise? Many thanks.

Can you advise on how long the automated links sent via the Customer Portal 'Forgotten Password' automate process are valid for? Most systems apply an expiry period on this type of links to stop interception/man in the middle attacks. Cheers Martyn

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 does not apply when configuring expiry times on human tasks. Human tasks do not account for Working Time Calendar and as such the above setup does not apply in this scenario.

Though most of our workspace posts we would want to retain, there are some that are only useful at the and are no need to be retained in the long term. For example posts advising the team of rota changes, people of sick, people on site this week etc, do not need to be retained. Therefore it would be useful to have the ability to set an expiry date and time on an individual post, which would mean that it is deleted automatically once the specified period has passed. Cheers Martyn