Jump to content

Applicaiton Rights to assign/complete other users activities


Martyn Houghton

Recommended Posts

I need to give my 1st Tier team the permissions to edit and complete activities on requests they have access (i.e. they support the service)  to but are not the owner. I can do this as a system admin but only want to give them the permission to do this not everything else.

Cheers

Martyn

Link to comment
Share on other sites

Hi Martyn

Could I ask, are you wanting your 1st tier team to also deal with all other aspects of the requests assigned to them?  as well as edit / complete tasks assigned to the requests?

In regards to the activities, when these are created in the BPM, you can set an Owner and an assignee, and the assignee could be a user, role or group.  If you used a group or role for the activities then users with this role or in these groups should be able to edit / complete the activities, or is this what you are doing and the question relates to the role these users need in order to edit / complete?

Sorry if I am misunderstanding the issue here?

Steve

Link to comment
Share on other sites

Steven

The activities are created in the BPM and assigned to the Request Owner  (Owner for Tasks). The requests themselves are not currently assigned to the 1st Tier team, they are updating them based on update being received over the phone or via emails.

For example at the moment we have a number of stages where we suspend the workflow when the request is waiting to come off hold. When the request comes off hold a new 'pending' activity is assigned to the request owner, however there are cases when it comes of hold when the activity does not need to be created, such as when 1st Tier are chasing the request and putting the request back on hold. The request has gone back on hold, but the owner of the request still has a pending activity for the request.

This is coming about as at the moment there is not concept in the workflow of who is undertaking the update. If we where able determine if the update is being done by the owner, the system (hold time expires) or other co-worker we could branch the workflow appropriately. However at the moment a member of 1st Tier, who are a team which support the service (all our services) can update the request but are not able to complete/cancel/reassign the activity.

Would it work if I was to make the owner of activity the Service Desk Team who all analyst are a member off?

Cheers

Martyn

 

 

Link to comment
Share on other sites

Hi Martyn 

You can assign the activities to the teams, which will give anyone in the team the ability to edit or complete.  Only the owner can delete the activity.

There is also the consideration of noise. depending on your request volumes, if every member of the 1st line team is being assigned all activities, this will result in a lot of activities in their lists and the supporting notifications .

A couple of things to consider

Regards

Steve

Link to comment
Share on other sites

Hi,

I too have an issue around this which is proving problematic here.  My example is the following.

An Analyst is working on a call that he owns, for some reason the call needs to be passed to another analyst for completing - the only problem is the new analyst is unable to complete the activity that is already created as like Martyn we have then assign to the 'Request Owner (owner for tasks).

It is setup like this as we work as one team and I don’t want everyone receiving notifications each time an activity is created as this in its self will frustrate people.

This has also happened when someone has taken on a call as the other analyst is off sick.

I’d be grateful for a resolution around this as it’s very frustrating and restrictive.

Thanks

Tina

Link to comment
Share on other sites

  • 1 month later...

@steven boardman

 

Assigning an activity to a team is not an option for us given the volume of requests we go through and the person update the request is not in the same team, i..e. request is assign to an owner within the Document Management support team and it is a member of the 1st Tier who is updating the request to advise that the issue has been resolved following an 'Update Request' from email. Ownership of the activity needs to be with an individual not a team, but we require the ability for the request to be updated by others, namely our 1st Tier Team or members of the same support team.

We have tried to look at how we can cope with this in the workflow itself but that has no awareness of who is undertaking the update/activity on the request, hence the relates forum post below.

This is possible by granting service desk admin role, but do not want to give all these rights to the other team members. I have a further look at the permissions on the role and there does not appear to be anything speicific to the ability to update and change activities for which you are not an owner.

Cheers

Martyn

 

Link to comment
Share on other sites

  • 3 weeks later...
  • 4 weeks later...

@steven boardman @James Ainsworth

 

Just wondering if there has been any planned changes to address this issue of being able to grant permissions to users to update/complete activities owned by another. The users, in our case are our 1st Tier team, who are a team which support the 'Service' the requests are logged against, but the request and the activity will be owned by a 2nd Tier user.

Activities are assigned to the individual request owner as they are the one that are responsible for the request, but 1st Tier will be updating the requests based on feedback from the customer, i.e. confirm resolution of the request, so they need to be able to complete the activity in the workflow so that it then progresses to the resolution stage stopping the SLA timer. At the moment we take the incident of hold and have to wait the 2nd Tier person to pick the call update up and complete the activity themselves which is then affecting the SLA response timers etc.

Cheers

Martyn

Link to comment
Share on other sites

  • 1 month later...

@Gerry

This was the specify issue we discussed a couple of weeks back regarding the ability of the workflow to have some sense of context so that when a request is updated by someone other than the owner of the request that this can be picked up in the workflow and the resulting activity assigned to the person updating the request not the owner. 

Cheers

Martyn

Link to comment
Share on other sites

@Gerry, @steven boardman, @James Ainsworth

Just a follow on from this, without the ability to grant a a team member the permission to re-assign an activity, means that even though the person can re-assign request to themselves the BPM activity is still assigned to the original owner of the request, so the BPM process is stalled. 

This is a major issue for use where there will be multiple people update a request not just the owner. 

I can understand why by default you would not want to automatically re-assign pending activities when re-assigning a request, i.e. where there are parallel activities with different people, but having the option at the time of re-assign to manually select to re-assign pending activities as part of the inline request update would help.

Cheers

Martyn

Link to comment
Share on other sites

Sorry to jump om this topic, but I had a word with @Victor recently about delegation of tasks for analysts, as we have the same challenge. Last time I heard, he was looking into it. Maybe Victor can provide some news?

If we could grant the rights for analysts to delegate tasks themselves, then you would be able to overcome your current challenge, no? I know it would work for us.

  • Like 1
Link to comment
Share on other sites

As previously mentioned this is an issue for us and we are unable to progress calls with activities for other analysts - we can currently only update it and wait for them to process when they return.  I know my colleagues would be pleased to hear an update on this.

Thanks

Link to comment
Share on other sites

All,

The plan is to provide different behaviour for task completion when you action a task from *within* the request view. We will be adding Service Manager application logic that will internally elevate for the purpose of allowing the task to be completed, we will probably add an application right to control this behaviour.

I will follow up with SM DEV team and get someone to post an update

Gerry

  • Like 1
Link to comment
Share on other sites

Hi @Gerry, All,

Thank you for the update! I would like to reiterate that we ( @m.vandun and me) have been struggling with the current behaviour a lot as well. Not being able to solve each others tasks has led to us mostly abandoning the tasks within requests functionality. Thank you @Martyn Houghton for staying on top of this thread!

Will be following this thread closely!

Thanks,

Alex

 

Link to comment
Share on other sites

@Martyn Houghton, @Tina.Lapere, @Alex8000 and @Lyonel,

Thank you for your posts! I would like to apologise on behalf of team Hornbill for the delay in our response and the inconvenience that this challenge is incurring.

We are currently investigating a proposed solution and a detailed plan to address this problem, without impacting the behaviour of the Activities functionality.

I would like to provide an insight into the proposed solution as soon as I have a confirmation of our approach, so please bear with me while we prepare this plan and I will personally update everybody here :).

Thanks,

Ehsan

Link to comment
Share on other sites

By way of a quick update on this one.  We have expanded the tasks implementation to provide a "hook" for individual applications to have more control over tasks created within their application, including the ability to use their own business logic to determine if the owner of a task can be changed, and by who.  The first stage of this is the core hook and has already been implemented and is in test, this should be out on dev and beta within the week ready for the Service Manager application team to pick this up and add the ability to to allow this. The effect will be that tasks created against requests will be able to be completed/reassigned by any user based on the application logic implemented in Service Manager (based in this case on who has visibility of the request to which the task is assigned). 

So you should expect to see this capability rolled out in the next 2.3 weeks.  We are sorry this has taken a little while but this involved changes at multiple layers of our stack and such changes need co-ordinating between teams. 

Gerry

Link to comment
Share on other sites

All (FYI @Martyn Houghton, @Tina.Lapere, @Alex8000, @Lyonel@ljbrown, @PSG),

I have documented a specification to undertake the implementation of - the ability for a User who is not the assignee of an Activity but is a member of the assignee's team(s) to be able to complete Activities.

As confirmed by @Gerry, we have tested the enhancement that was added to Hornbill Platform and Hornbill Core in relation to providing this ability. The outstanding work at the moment is for the Service Manager app to utilise these enhancements. This feature will be controlled by an Application Setting in the Service Manager app, which will be disabled by default. You will have to enable this Application Setting through the Admin Tool to use this feature.

I will update this post once the work in the Service Manager app is complete and I will let you all know when this feature will be available.

Thanks,

Ehsan

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...