Jump to content

Assignment node


Joyce

Recommended Posts

Hi,

I am trying to automatic assign a ticket to whoever created it.

So I am using 'Assignment node'', then choose task as 'Assign to creator'. All the option below it are auto (pick Request ID, pick team, etc).

When a ticket is created, it seems to fail at that node. 

What am I doing wrong:

image.png.e018c59a856bcd839268f488e009b195.png

 

 

 

 

 

image.png.be532f9567ebe7744a17a07ceb720f5f.png

 

Link to comment
Share on other sites

@Joyce @Dan Munns  the node requires a team in the "Team" parameter. it is suggested by the red line border. The value for this parameter can be provided in two ways:

  • Manual: requires a value to be provided in the node configuration (i.e. select a specific team from the drop-down menu);
  • Auto: the value will be provided during runtime, as Dan suggested, by the Get Request Details node. However, this requires that request is assigned to a team at the time when "Get Request Details" runs.

 

Link to comment
Share on other sites

@Victor if the call was assigned to a team, say service desk and then a Get Request Details node was used, then an Assign to Request Creator node, would it select the person who created the request and their team or would team stay as service desk and if the person was not in that team, fail? 

I was thinking about making a change to our 'First Time Fixes' BPM which uses Assign to Request Creator to include more teams as currently it only caters to service desk. 

Link to comment
Share on other sites

7 minutes ago, Dan Munns said:

would team stay as service desk

Yes

7 minutes ago, Dan Munns said:

if the person was not in that team, fail?

No. It won't fail. I mean it won't "hard" fail, with an error... but the request will remain assigned to "service desk" and no owner.

Link to comment
Share on other sites

Just now, Dan Munns said:

Is this limited due to possible multiple team membership or some other reason?

Ermmm.... Yes ?!  :D 

Your rationale makes sense but I honestly have no idea why... I just read the code behind the function to describe how it works... On the "Why?" bit... I think @James Ainsworth or @Steven Boardman might be able to answer this...

Link to comment
Share on other sites

  • 2 weeks later...

@Joyce - Did you figure out how to achieve the below? I'm looking to create the same scenario for password reset requests received over the phone, if for example 1st line are busy calls bounce to 2nd line then 3rd, etc. so the request creator isn't always going to be in the same team. @James Ainsworth do you have any further suggestions on how to achieve this?

On 1/29/2018 at 2:09 PM, Joyce said:

yes, but creator has to belong to the team. 

The scenario I am after, is just be able to assign ticket to creator, regardless of which team they belong. 

 

 

Link to comment
Share on other sites

@dwalby we have 2 password reset catalog items, one which the service desk (or anyone who can reset passwords) can access and one on the portal. 

The portal one is only supported by the Service Desk, the other is supported by all teams and has an 'assign to request creator' node. Other than the extra node they are both exactly the same.

Link to comment
Share on other sites

@Dan Munns - Thanks, yeah I've created 2 reset catalog items, I just can't seem to get the 'assign to request creator' node to assign to the creator - it errors, presumably because as previously mentioned by @Victor it needs a team to be specified. Is there anyway around this? As I say, we need to assign to request creator who won't necessarily always be in the same team.

Link to comment
Share on other sites

@dwalby Sorry, if you add an assignment node to the PC for the one used by the analysts it will have a team assigned at creation. You can even get rid of the assign to creator node in the BPM.

I think other wise you are looking at clever stuff in the BPM to work out the team. 

Looking at our BPM at little more closely it assigns to Service Desk before the node. And it has been mentioned by a couple of people from the other teams that they have to assign it before they can close it so that might be the issue. 

Link to comment
Share on other sites

@dwalby good stuff.

I think to be honest that that will be the only way to do it for a service supported by multiple teams. The issue you will have is that if an analyst it a member of more than one team it will be unable to work out which team it should assign it to.

Would be good to have a 'default team' per analyst though. @Victor any thoughts? 

Link to comment
Share on other sites

7 minutes ago, Dan Munns said:

Would be good to have a 'default team' per analyst though. @Victor any thoughts?

Yeah, seems like a good idea... :) ... I do have many thoughts :) ... however, I was "advised" not to express them in public :P ... (as I said on this forum some time ago, some of them are borderline outrageous)

 

Jokes aside @James Ainsworth and/or @Steven Boardman would be able to advise on changes and functionality requests :) 

Link to comment
Share on other sites

Hi @Dan Munns

We have considered default teams in the past.  At the moment in the Administration portal the team configuration comes under the Organisation Groups in administration and all of the apps available in Hornbill can use these teams.  The problem with setting a default team here is that a default team required for Service Manager may not be the same default team required for another app.

In Administration we have started building out an area for configuring the teams and Service Desks that use Service Manager.   This will allow us in the future to provide these types of settings.  We have a bit more work to do here before adding the default teams but it is something that we should be able to provide in the future.

image.png

Regards,

James

Link to comment
Share on other sites

On 29/01/2018 at 6:09 AM, Joyce said:

The scenario I am after, is just be able to assign ticket to creator, regardless of which team they belong. 

Hi @Joyce

Assigning a request to someone while it belongs to another team would have a knock-on affect in other areas.  If the owner and the team don't match up you may find visibility issues in the request list or inconsistencies in reports.  For security reasons we do our best to keep this scenario from occurring so that someone doesn't find themselves working with a team that manage secure data.

The suggestion of a default team may help in this scenario, but you may also run into issues where a default team  that the request gets assigned to doesn't support the service and again you are left with dependencies in reporting against that service.  

Do let us know if the suggestions posted above have helped get you to a point where this is working OK for you or if you are still having issues.

Regards,

James

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...