samwoo

I completely agree if we had to use formulas and calculations within the variables - so I thought it might be good to have been a node which we can input 2or more integer values then apply the calculation we want between the numbers, like we can do with other utilities in Hornbill Automation - still being codeless but offering advanced functionality. If there isn't anything currently on the pipeline, please could this be added to the list to be discussed internally? I envisage something looking like this: The number of integer and calculations could go as high as 10, and even if say Integer 4 is empty, Integer 5 might not be, so it should make an effort to calculate everything. This would be good if someone is creating procurement request and everything needs to be totalled up at the end. In my case, I'd be using this as a counter for a loop, so I just need to use Integer 1 and 2 plus the Calculation in the middle. Thanks, Samuel

That's great Steve - thanks! Now the more I think about what you said, the more it makes sense. I don't suppose there are any utilities in the works to enable addition/subtraction and other formulas to occur within Hornbill Automation? Cheers, Samuel

Thanks @Steve Giller, Is this because of the loop it's not able to identify it (even though it works)? The result reference is defined in the "Get Request Details" node further up the BPM, then repeated in this loop as you can see by the highlighted node and it's Properties. Here is the output variable from the Get Request Details node: Or is it because I've got the +1 at the end of it? (to increment the value by 1) that it's not seeing it as a Context Variable? (Pardon my ignorance if this is completely obvious) Is there a better way to do what I'm doing? Thanks, Samuel

Good morning, Nothing major, but I have been setting up my BPMs for the SLA functionality and I have just noticed something misleading in my "Generic Incidents Requests BPM" and "Generic Service Requests BPM" where I store information in the Service's Custom Fields for any Services that uses these Generic BPMs to pull the data out of these fields. I have two nodes... one near the start and one further down the stage that captures the Request Details (Get Request Information -> Request Details). Both nodes uses the same Result Reference, but are called at different times... this is to overwrite the old with the new (if required). With this node, I then update the Custom Field 26 against a request... effectively being used as a Counter. It starts off at 0, then if someone continuously completes a Human Task without carrying the action required to move the request on, the counter will go up. This is really for providing a visual indicator that they are repeating the same action multiple times. This all works... perfectly. I'm impressed... but the Update Request Details node is providing a misleading warning (I think): In case you are curious, here is the part of the BPM that utilizes this (we don't allow users to set the Request Category): Is anyone in agreement that this warning should not really be appearing at all, despite the process working as intended? (What would be nice is if the nodes that carry out any update actions, can also store the previous value and new values in their results, which means I can do away with having multiple Get Request Details nodes) Thanks, Samuel

+1

Hi @David Hall, Just confirming that your advice to just have the 1 Service Level Agreement with different Service Levels for the different companies have worked. Now the next issue is why isn't the response timer and/or resolution timers not showing for some tickets... despite the Service Level Agreements and Service Levels being set correctly. My guess is due to the order of the nodes in the BPM (which sets the priority and starts the timers) ... In tickets where the Response and Resolutions Timers have not been set, the Priority is set AFTER the timers have started. In tickets where the Response and Resolutions Timers have been set, the Priority is set BEFORE the timers have started. Can you confirm that this is correct? Does this likely mean that I will need to update all the BPMs to change the ordering of the nodes? There is no mention of this (that I can find on the Wiki) alongside the other information you provided above. Many thanks for your assistance with this, Samuel

Hi @David Hall, Thanks for sending the details of the process - I think that would be a good fit for the Wiki pages. In terms of my issue, I have reordered the SLA against the Service and it appears to have picked up the first Global SLA in the list. It also assigned a SL from the Global SLA to the request too. You mention that this is due to there not being any rules in the Global SLAs to determine which one to use, but both Global SLAs have rules in them... one to check for Company W (and priority) and the other one to check for Company O and Company B (and priority). Then you mention there are two rules configuration (SL and SLA) - can you confirm that setting the rules against the Global SLAs themselves should be more than enough? Or should I also be assigning rules via the Service SLAs section against a Service as well? If really hope I don't have to go through every single Service to set this up to select the Service SLA rules... but I did a test by adding the rules to the Service SLA rules area - mimicking what I already had against the Global SLAs themselves, with the Service SLA Rule for Company O and Company B at the top and the Service SLA Rule for Company W at the bottom. Doing this, then raising a ticket has assigned it to the correct SLA... despite the rules being the same as the ones in the Global SLAs rules. Thanks, Samuel

Hi @David Hall, Yes - I have multiple global SLAs, but there are 2 main ones that are used for most Services One of the SLAs is for the main company (let's say Company W) The other SLA is for two other companies that we manage the IT Support for (lets say Company O or Company B ) Yes - I have Service Levels described as Priorities 1 to 5 in both main global SLAs, each with the Response and Resolution Targets set. In each of the SLAs I have rules that define which Service Level should be used. The rules primarily check for: The Company the user works for The Priority set against the request (P1, P2, P3, P4, P5) For the P3 Service Levels I have an additional condition to only be used if the Request Type is Incident For the P4 Service Levels I have an additional condition to only be used if the Request Type is Service Request All of our Services have the SLA that looks for Company W. Most of these Services also has the SLA that looks for Company 0 or Company B. In the case of my test user, he works for Company W. When the ticket is raised, it is being assigned to the SLA that links to Company O or Company B... Thanks, Samuel

Hi David, Sorry I have been rushing about doing some work on this that I didn't say that all the Services have the SLA's against them for all the companies.

Wait do I have to set up these rules within the Services for each Service as well? I was hoping defining the rules at the top level (outside of Services) would suffice?

I don't use Sites in my SLA's and all users (hopefully) should be assigned to a single Company, so do you think my set up should be working, without the issues you were experiencing?

Looks like I'm missing some text from the end of my previous post... "Is there a way to debug this, or to see exactly what is happening?" In addition, I've gotten reports that for some new tickets, they are being assigned to the incorrect company-based SLA. Here is an example: This person is a part of the company beginning with W, and for some reason this request is point to the SLA related to the company beginning with O.

Hi @David Hall, That's great thank you - it wasn't very clear on the Wiki Pages where that comes from. So the users have already been assigned to the relevant company a while ago. I even went in as a test user for the company that comes second in the SLA list... When I logged a ticket as that test user, the ticket was assigned to the first SLA in the list... despite that SLA looking at a very different company. Below is my test... Here is the SLA rules for the second company - the one I expected to be assigned to based on the company my test user is set up against. Here are the SLA rules for the first company. I have some duplicate Companies since I initially (a long time ago) made one of them a child of the main company accidentally. This is the SLA that is incorrectly being assigned to my test user. Here is the company for my test user (starting with W) But the test ticket I raised is being incorrectly assigned to the wrong Service Level

Good afternoon, I have been setting up the Service Level Agreement functionality, to keep in with support prior to the removal of the old functionality. I have been setting it up to auto-set the SLA based on the Company the Customer works for. But this is not working at all... it is setting the SLA to the top-most in the list of SLA's against the Service. I then wondered if "Company" was used against the request, and there is a field called h_company... so I then had a look at the bpm configuration - specifically the update request node, and there isn't any way to set the "Company" of the request. Can you advise on how I can set the Service Level based on the Customer's company? Most of the Services applies to all Companies (3 of them) but they have different SLAs. Thanks, Samuel

+1 BUT the only downside I see for this is if you have Routing Rules to update tickets, and you send an email via Hornbill, if that person has an out of office and your sub-statuses are set up accordingly, then it will take the ticket off hold again... then you have to put it back on-hold anyway. But one less clicks makes a difference, especially where there is no auto reply coming back.