Berto2002

@Daniel Dekel the global search has sometimes defaults to "Coworkers" so there ARE sometimes two clicks required to search for Requests (or ALT-X plus a click). Your statement about it defaulting to "Requests" seems correct for the this screen (https://live.hornbill.com/xxx/servicemanager/requests/) but when I click the search from say Board Manager (https://live.hornbill.com/xxx/boardmanager/board/5/) or Supplier Manager (https://live.hornbill.com/xxx/suppliermanager/suppliers/) or the portal view (https://live.hornbill.com/xxx/internal/catalog/hr/) the default is Coworkers. So looks like the default of Requests is only working for Service Manager...

We have such low volumes of such tickets we have not tried this. Note these two requests though:

Had a look at this and we also search for the applications a user is in when we have a Mover ticket; and we cannot allow this to be destructive as they are not leaving. So this is now the use case we have no workaround for (other than planning to ensure we have no more than 10 apps configured for any given OG type.

@Sam P in the last, our analysts have reported they cannot schedule changes in a freeze so this may be a permissions issue. What perms do you give these Users? I think Change Management Full Access gives ability to over-ride freezes. As a change manager, I can always schedule etc but that's how it should be.

i have sent you an example procedure which might be useful for you. @Tina.Lapere.

One year on, I wonder if any other customers would welcome enhancement in this area: Enhancing the Autotask functionality to be more of an on-demand sub-workflow that can accept, update and process variables. I believe this will be very powerful. The main reason to have it would be to enable execution of operations any time in the lifecycle of the Request where the chronological nature of the main Request Workflow/BPM normally only allows those operations at certain points in time. The example of booking a calendar appointment is good: you cannot predict when it will be possible due to the variable of when the customer replies with availability so an ability for an on-demand 'task' to pop an input box and use that input to update a Request variable field/custom field and then operate on it would be very useful

@Ben Maddams and @HHH I will use this as an opportunity to see if you'd like to support this long-requested feature of enhancing the Autotask functionality to be more of an on-demand sub-workflow that can accept variables. I believe this will be very powerful. The main reason to have it would be to enable execution of operations any time in the lifecycle of the Request where the chronological nature of the Workflow/BPM normally only allows those operations at certain points in time. Your example of booking a calendar appointment is perfect; you cannot predict when this will be possible to do and may want to do it at multiple stages of the main Request Workflow so the ability for the Autotask to pop an input box and use that input to update a Request field/custom field and then operate on it would be very useful.

@Amanda Durgan are you using Supporting Teams in Service Portfolio? Is that team with the issue listed as Supporting Team for the Service or Services having the issue?

After a Get Customer Details Workflow node we see a lot of "% Custom %" fields: We are about to sync the Cost Code from AD into Service Manager and I am about to nominate one of the Customer Custom Fields (below). We know these are the "Customer Custom x" fields above because they work as such for our Basic Users and are available to view in the User Profile screen (see below). Knowing there is a "Costcenter" field somewhere I would like to use it. I cannot see any "Costcenter" fields in the User profile for Full or Basic Users (they are not listed in the "Custom Fields" tab), let alone custom fields for costcenter, company, department and division. Short questions: 1) in an AD sync (LDAP user import), what field name do we put in the import script to hit the "costcenter" field above and 2) where can we view that in the UI for our Full and Basic Users?

+1

Yes I can select "dynamic drop-down box" option in both Workflow and ICF but my "data provider" options are only simplelists in Workflows; whereas in the ICF sister function, there is a "Provider Type" which allows selection of "Simplelist" or "Data Query" and then the latter onwards shows the "Data Provider" with different "pickers" (including the new one for members of an organisation group). What I am highlighting is that it looks like at one stage the ICF and Workflow versions of these "Field Type Settings" were created to do the same job but they have diverged or not been kept in line as time has gone on; so there are different capabilities in each. At the high level I am really requesting these be aligned. In Workflow: In ICF: Workflow options in the Field Type include the two "pickers": The Provider Type which is "missing" from the Workflow version, behind which the ICF version allows so much more rich selections: As a result of this, my Basic Users can select a user from an Org Group but my Full Users have no functionality to be able to do the same, as an example.

Hmm, that's weird, it's now working. Well great!

Has anyone reported that the "customize columns" does not work in the UI Preview in the Request List? I click it and nothing happens. I need to switch back to the 'old' interface to be able to get the button to work. @Daniel Dekel

That would help in the Leaver case, certainly. I will have a think through that idea. But it's a 'destructive' approach so could not be used in any case where membership of the groups is still required.

We use this node quote a lot to discover what Organisation (organization) groups a user is in when they leave, so we can trigger removal requests and remove them. The nodes returns results for up to 10 instances of the given group type; in the case above, this was "General". We often paste this on the timeline for service desk visibility thus: We use Org Groups for Subscribers to individual Services (applications) and the workflows add and remove users to these OGs each time the app team action create or remove a user. I want to expand this facility but can you guess the issue? That's right, it won't be long before our users are members of more than 10 OGs of Type General. And then the workflow nodes will only 'Get' the first 10 and then we won't be able to act upon all their apps when they leave. So I think I am highlighting what looks like a hard-coded limitation that is going to stop us expanding the use of our 'automated' subscriber list management system. And this, in itself, holds us back trying to make the portal easier for everyone by only showing the Services (apps) they have access to. Yes, we have other OG types that could give 10+10+ etc but that means spreading my workflows for this activity across the types which will be confusing to manage and won't guarantee the issue won't occur because any given user may end up with the exact spread of 11+ apps that are in any given type. I mentioned this in the HUG23 to Dave in TS but I don't know Dave's handle on there to alert him. Can I please request a review and to get back to me on what we can do here to rectify or me workaround this limitation? Thanks, Rob

Ah, ok, yes, I would endorse that this should be on ALL Requests (if in the team) because about half of our initial assignments use "most available" or "round robin" assignment in workflow so the button will rarely show. Analysts do need to dive-in and take ownership from other analysts in the team sometimes (easier for someone to say "I'll grab that from you" than ask them to "please assign to me"). +1 for all Requests (assuming user is in the same team); because it's quicker than using the re-assignment function.

@Paul Chambers should be fixed in release last night ( 2.157.0 (2973) )

Eager to find it...

Some time ago I requested that Hornbill introduce a feature to allow a Customer to select the members of an Organisation Group when logging new Requests. Hornbill fulfilled it with this feature which was great: BUT there's a very similar place in the Workflow (BPM) where the pickers are configured in a similar way but we cannot select from the users of an Org Group. From a use-case perspective, we have a problem now where the user can select a member of a group but if our service desk detect that person is out of the office, they cannot re-select another one using the same criteria! So we cannot migrate away from using a simplelist for this feature because we need both the user and the service desk to be able to select from the same list.... We need the same feature there! I request it please; select from org groups.... I wish I had asked for it in the same time as the ICF!!!

In terms of a visual I think I'm drawing-out that it seems counter intuitive that these two elements of email template configuration are referring to different email templates and only one is configurable per service.

I thought that selecting the Email Template here: Would mean that that email template would used for all Customer-visible Updates made through the UI but in my testing it continues to use the default as per the application setting: Of course, that template does become the default one used when entering the Email action of the Request. But is it correct that the setting only impacts the Email action and not the background default template used for all updates? Wouldn't it make more sense for it to do both?

+1 to use the members of an Org Group to do this.

I don't think that's possible. All the relevant variables are here:

Any more?