Steve Giller

If a Task has an Owner they can reassign the Task at any time, or if the activity is assigned only to a group, any user in the group is able to assign the activity to themselves or another user. It is important to understand that a Task is not part of Service Manager, they are Collaboration Activities that are linked to a Request but there is no requirement to do so. A Task may be linked to a Request, a Project, be completely stand-alone etc. so "following a Request" does not make sense in the same way that an email to me about a Request does not become an email to someone else if I hand the Request over. Any Role with the Advanced Request Task Completer Right (see the foot of the Activities wiki) will allow someone to complete tasks on a Service Manager Request that are assigned to another user, if they support the Service. (If they don't support the Service they can't be assigned the Request anyway.)

The relationships between Assets and Requests are stored in the h_cmdb_links table. The Assets and Requests are stored as URNs, not IDs so you will need to manipulate the data in order to achieve this report. Please bear in mind that this is not a one-to-one replationship when viewing the results.

If this is a major issue you can always lock the Assign action until the Activity is completed. (See the Access Control section of the wiki page.)

@Salma Sarwar My apologies, for Groups h_notes is limited to 255 characters, for Organisations it's an unlimited field.

You are locking the Resolve/Close Action, not the Request, so other actions are still accessible. Email is a completely separate application, until you process an email (whether manually or via Routing Rules) the system has no idea whether it's related to a Request. I am assuming you're referring to Routing Rule updates here, these do not update Cancelled Requests.

There are multiple search bars in a number of locations - can you also clarify exactly where he's searching?

@SJEaton Yes, that should be fine, it works on my Instance.

Just having those screenshots to go on makes it somewhat guesswork, but I would suspect that there is a rule in the UK SLA (not the critical one) that is being picked up. It looks like from that setup all UK SLA rules will be applied before any of the US Rules are.

I'm not aware of any planned changes in this area but as this post is tagged as an Enhancement the Developers will get to see it.

I'm not aware of any planned changes in this area, but as this post is tagged as an Enhancement the Developers will get to see it.

I'm not sure what you're trying to achieve here, but reporting on this table is not recommended due to the size and complexity of the content, and because the restrictions we have in place to maintain performance will frequently cause reports to return an empty recordset as the query has timed out.

The h_itsm_request_team_assignment table will probably assist here.

That may depend on how you have this set up. How is the question configured in the Capture?

If you could add your support (and possibly your business case) to this thread it will help the Team to prioritise it within the existing queue. Customer engagement is not the only factor, of course, but it does influence the priority.

This is not available, mainly because although you may be linking a single asset, there are potentially an unlimited number that could be linked to a Request. We can make things like the Owner or the Customer available to email templates, as there are only one of these per request (at any one time) but this is not practical when there are multiple possible values. It may be worth adding the Data Governance team as Connections for these requests.

Without having access to the Capture, all we have to go on is the error - this is basically saying that the Capture is not configured correctly and this misconfiguration must be corrected. Unfortunately the message does not specify where the issue is, it may be worth checking each node for an empty mandatory parameter, or any parameters like field IDs that do not have a value, or an ID or less than 3 characters.

I would suspect that either there are requests without an SLA, or there's another criteria I'm missing. Probably one for one of our reporting experts here, unless you can specify h_withinfix is not null, maybe?

How is he searching for it? If he knows the Request Reference the best option is the CTRL+SHFT+F shortcut which will take you directly there.

@Stefania Tarantino I uploaded James's report onto my Instance, and removed the filter on Request Status to show: and this returned all of my suspended Workflows. It's possible that the query is timing out (as Victor mentioned, it is a table which is not quite designed for reporting) so you might need to reduce the size of the results. As the Closed filter does return a recordset, maybe filtering on each status in turn rather than trying to dump the whole set?

h_withinfix can also be null, so without picking the report apart (which I'm not very good at anyway) my assumption would be that accounts for the "missing" 44%

@QEHNick Are you restricting the report to statuses of closed/resolved? Do you have any Requests that don't have an SLA attached? I'm sure there are more gotchas here, but they're the ones that spring to mind.

@Stefania Tarantino "Suspended" is a valid state for a Workflow. Waiting for an Update, an Owner, an Impact Assessment, Customer Feedback (there are dozens of these) will all have the Workflow in a Suspended state ... for example: It appears from the above post that you've formed the impression that a suspended workflow is in some kind of error state - this is not the case, so canceling these could severely impact the Requests they are attached to. Even if you have Closed requests with a suspended workflow this does not necessarily indicate an error, for example they may be awaiting feedback.

@Ketan.lakhani I'm not sure what else we can offer here - Microsoft code 49 is "invalid credentials" and LDAP code 532 is "password expired" The Import Tool is only reporting the error that your LDAP environment (presumably Active Directory) is reporting, which is that the Connection is being refused due to invalid credentials. The connecting User Account is the one set up in your Hornbill Keysafe as detailed on the LDAP User Import wiki page.

From the LDAP wiki I see: So the error may be coincidental and the credentials you are using to connect to LDAP may need updating.

This has been identified as a defect and will be fixed in the next Service Manager build.