Jump to content

Multiple people interested in request - portal visibility


chrisnutt

Recommended Posts

Hi,

There are many situations that I have come across where people want/need visibility of requests raised by other people. One such example is our Contact Centre raising faults that stem from Finance issues with our systems. Finance contact the Contact Centre to investigate and then the Contact Centre raise a fault when they find one. In this scenario, Finance needs to be kept informed. The connections feature is nice, but it doesn't lend itself to the portal as far as I know. Is that possible? Is it something that can be enabled? Or is there another way I haven't thought of/noticed?

We have other scenarios where departments want visibility of others requests purely because we have a lot of casual staff members who are not here all the time.

Put simply, I would like the ability to be able to make some requests (by service or by business process) visible on the Portal for someone other than the customer.

Thanks

Chris

Link to comment
Share on other sites

Hi Chris,

To be honest the system was never really designed to support such a data model.  Our customers are typically wanting a high degree of security around the data they hold in our service, and as a result we have built Hornbill around a very comprehensive security model.  It has always been envisaged that access to the requests via the portal is for customers, specifically the customer logged into the portal.  Providing access and visibility to the requests is applied through a security layer which verifies if the user should have visibility.  I believe this only checks against the user logged in and therefore only sees their own calls.  Now I believe (and I hope someone with more SM expertise than me can verify) there are two exceptions to this. 

1. If  you configure a manager in a users profile, then the users manager can see that users requests. 
2. If your user is the member of a "site" and you are flagged in that site as the site manager then you would be able to see that users requests also. 

In all other scenarios where people would need visibility we envisaged in our design that they would be Service Manager application users where we have obviously built the majority of the flexibility in terms of visibility. 

I will need someone to confirm the above two exceptions but I think thats right.

Gerry

Link to comment
Share on other sites

Hi @chrisnutt This was fixed by Trevor a while ago, there was a setting introduced called ManagerSearchField which will change the field that is being searched for the ID of the relevant manager. The details are on this page here: https://github.com/hornbill/goLDAPUserImport and I will update the relevant thread in case anyone else has a similar issue. You will need to download the latest version of the LDAP import script to take advantage of this feature (in case you haven't already).

Thanks

Conor

Link to comment
Share on other sites

@chrisnutt @Martyn Houghton I see now, I understand where it comes from... I was trying from "Releases" section... anyway, the URL here is indeed wrong, It contains an extra "v": https://github.com/hornbill/goLDAPUserImport/releases/download/v2.4.2/ldap_user_import_win_x64_v2_4_2.zip

Try this URL meanwhile, it should work fine: https://github.com/hornbill/goLDAPUserImport/releases/download/2.4.2/ldap_user_import_win_x64_v2_4_2.zip

I'll mention the broken URL to Steve TrevK so he can fix this.

Link to comment
Share on other sites

  • 3 months later...

Hi All,

I recently received an email from our contact centre that once again is crying out for the functionality that I described all the way back in the first post in this thread before we all got distracted with the other issue inhibiting the view for managers I was experiencing. I will post the content of the email verbatim below.

Quote

Dear Chris,

I spoke to <Contact Centre Manager> last week with regards our team having shared access to the IT and Estates portals,  so that we are able to log issues and requests as a team rather than individuals. She mentioned that there was some difficulty going forward with this plan through our individual accounts. I was wondering whether it might be possible to create a user account for our team, in the same way that we each have an individual account. This way when logging IT or Estate requests we would log into that account instead. The main reason being is that as we work 7 days a week, not everyone is in on the same day therefore we find ourselves logging the same issue twice as well as being unable to double check AV or Estate requests placed by another member of the team.

It was just an idea and I look forward to hearing from you.

<Contact Centre Advisor>

As you can see, they are desperate for the functionality - beyond what is available to just the manager or site manager. In order to achieve it, they are requesting a shared account, which I'm sure you'll agree is not a great idea for myriad reasons.

Can I ask that this functionality is considered to be developed, but with tight controls that an administrator can edit? There is clearly a need in departments that have casual staff or are 7 days a week and reporting issues to be picked up by colleagues.

I have three high profile departments (Contact Centre, Memberships team and Finance) constantly asking me for this and it is not an issue that is just going to go away when I explain the system doesn't work that way. For example, I spent a long time developing a process for a single type of request that sends email notifications to everyone needing visibility. It is not particularly elegant. Doubly so because many people work with third-party portals that do allow this functionality.

Thanks

Chris

  • Like 1
Link to comment
Share on other sites

@chrisnutt

I am trying to understand how such a capability would work in practice?  You have one or more basic users who are part of  the same team (Contact Centre for example), and you want them to be able to raise a request, but not have it allocated specifically to them, you want any one in the group to be able to see these requests, update them etc... from the support provider point of view I presume you would want them to interact with the individual that raised the request?  unless told otherwise? So there would need to be a notion of both the "requestor" and the "requestor group" so to speak.  Nothing is impossible but I expect there is a lot of complexity involved in changing the underlying data model and making it work like this. The problem is, most customers do not want the system to work in this way so it would have to support the current model and this new model, and I bet there are a  hundred little things that would need to made to work in this way that we cannot even think of.  I say that because there is so much code developed with the current data model assumed.   I think its more likely possible to make it so a team of people could have visibility in the portal, but the functionality of groups only works with Collaboration Users and not Basic Users... so anther challenge to overcome three - how we would define the "Contact Centre Group/Department" for this purpose. 

I know this is on the backlog to have a look at but I am not sure there is a simple solution to this - its somewhat more than just a tweak. 

Gerry

Link to comment
Share on other sites

Hi @Gerry

Thanks for your response.

I didn't think it would be a tweak, but instead quite a substantial undertaking. Up to this point, I hadn't been made aware that something like this was on the backlog though. That information alone will go a long way to placate the people asking me about this on a monthly basis.

To be clear, the functionality I am talking about is not to allow a group to log a request - this was their workaround using a shared account. All they want to be able to achieve is to view requests raised by others in their department. The majority of requests I receive are for visibility within a department. Carrying on the Contact Centre example, on a Saturday Person A may have an issue that a colleague - Person B - raised on let's say Thursday. The manager isn't in so cannot be asked to check requests. So they can't do a huge amount but log it again to ensure something is done. Frustrating for them, and for us.

So, if there could be a way to allow a person within a department to be able to view their department's requests in the same way, practically, as a manager does through the portal it would be a huge plus (I'm aware Supportworks could be made to work like this). The customer can remain the individual who raised it, Person B, but we'd give Person A the ability to see their department's requests (or to put it another way, Person A can see all requests that the manager of Person A and B can see through the portal), with appropriate authorisation of course.

Please, may I be kept informed of the progress of this on the backlog?

Chris

Link to comment
Share on other sites

Hi @chrisnutt

As you have mentioned, there is a change in our backlog for us to look at options for allowing requests that have Connections to be visible to those connections on the portals.  Even if the visibility is controlled through the Service or BPM, we have to have a way that a user knows that their information may be shared, in order to prevent any personal or secure information from going out unexpectedly.  We have to be careful of our security models and make sure that we are not inappropriately exposing information to other users that we shouldn't. 

As mentioned by @Gerry this is not currently scheduled so mostly likely not something that will be available in the short term.  The publishing of a problem record would be the current solution to provide information, however this would be visible to all that subscribe to a service and not restricted to a department.

Regards,

James  

Link to comment
Share on other sites

Thanks, @Gerry, @James Ainsworth

I understand that it is a ways off and not on your 90-day path, but just knowing it's being discussed puts me in a better place than this time yesterday.

Publishing a problem is not suitable, because the things being reported are not problems. They are incidents and Service Requests. Also, they can't be raised via the portal by the customer (which is absolutely correct) and would, therefore, create unnecessary admin for the Service Desk here which I would not accept. Not to mention skew reporting and cause confusion at problem review time.

I look forward to updates on this.

Chris

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