Can Connections View Requests?

[Claire Holtham]

@Steven Boardman and us please!

[Steven Boardman]

Thanks @Claire Holtham @Keith i've added you.  This story has plenty of interest so definitely going to help with it's priority  

[SJEaton]

Thanks all for supporting this idea!  

[dwalby]

On 5/3/2018 at 1:46 PM, Guest said:

Hi @dwalby 

You can't put conditional criteria such against a manager mapping currently. But you could run two import scripts - the first one for all users who should have the manager mapped, and the second one for the users who shouldn't (simply disable the Manager Lookup in the configuration for these ones). 
You would split these groups of users up by either using the DSN and/or the LDAP filter attributes (e.g. in this import do not include anyone who is a Member Of the finance team)

Kind Regards

Bob

Does anyone have any experience with running 2 x LDAP import scripts? Whilst we await the ability for connections to view requests I'd like to exclude a particular OU from getting the 'Manager' attribute mapped, so I can then manually set the manager within Hornbill, allowing one of the department operational managers to view all of the requests within their department.

I even looked at changing all of our BPMs to facilitate this - changing the customer at the point it's logged, etc. but couldn't see a way of keeping the original request raiser informed of progress

[Cizzling]

We are also +1 on having connections being able to view a ticket - and as for @Martyn Houghton our focus is the customer portal and external customers.

[Jeremy]

we have mentioned this before also, +1 for us at UoP

[Giuseppe Iannacone]

@Steven Boardman +100 Also here, Please help us to raise the priority of this request, I believe all the customers will take advantages of this development.

[Steve Giller]

+1 here

 

[Steven Boardman]

@DeadMeatGF @Jeremy @Giuseppe Iannacone @Cizzling you have all been added or where already on the interested list. 

I can feedback that this is one of the top requested features, it is in planning and we'll post back here once scheduled and a firmer date for availability is known

Steve

[HHH]

+1 for allowing connections to see a request

[Steven Boardman]

Thanks @HHH we have your organisation added as interested. 

[davidrb84]

+1 too for us please.

[Steven Boardman]

@davidrb84 thanks you have been added

[dwalby]

@Steven Boardman sorry to chase on this, are there any timescales for this development?

We now have a requirement to log GDPR/Data Breach incidents through Hornbill. When a staff member logs a Data Breach, 2-3 managers within the department must have the ability to view and update the Data Breach, regardless if they're the requester's line manager.

Is there anyway to achieve this in the meantime?

[Steven Boardman]

Hi @dwalby there is no timeframe on this i am afraid at the moment, as soon as there is we will post back here.

Just looking at your example here, if a customer is raising a GDPR / Data Breach Incident, the customer of the request only has the ability to add comments to the Incident, upload attachments, or comment on other posts in the Incident timeline.  

Where you are suggesting the 2/3 managers in the department must have access to view / update the data breach, could you elaborate on what that would mean in practical terms?

I ask because with the story to allow connections some level of visibility of a request may not afford them the same level of capability as the customer of the request and certainly no more.  We have to be very careful with this story that we don't cross over the divide between a customer logging an issue, or raising a request for something, and someone working on the issue / fulfilling on the request - as this would in Hornbill terms need a Service Manager subscription.   

This is why i am keen to understand the expectations of the division managers in this example?

In the meantime a possible solution would be as follows:

1. Capture the data breach information in progressive capture

2. Inject this information into the summary / description or custom fields of the request

3. Add the division managers as connections

4. Automatically (or manually) email the division manager's an email template containing the information the need to view or comment on

5. They can email back any questions / actions to the Incident which can be actioned by the support team who own the Incident 

6. The automated emails to the connections can be built into the supporting business process at the required touch points, not forgetting you can now use custom questions on the Incident tasks, and the task outcomes to these questions can be injected into request custom fields and emailed to the request connections via email templates. 

Thanks

Steve

[dwalby]

On 10/25/2018 at 7:46 PM, Steven Boardman said:

Hi @dwalby there is no timeframe on this i am afraid at the moment, as soon as there is we will post back here.

Just looking at your example here, if a customer is raising a GDPR / Data Breach Incident, the customer of the request only has the ability to add comments to the Incident, upload attachments, or comment on other posts in the Incident timeline.  

Where you are suggesting the 2/3 managers in the department must have access to view / update the data breach, could you elaborate on what that would mean in practical terms?

I ask because with the story to allow connections some level of visibility of a request may not afford them the same level of capability as the customer of the request and certainly no more.  We have to be very careful with this story that we don't cross over the divide between a customer logging an issue, or raising a request for something, and someone working on the issue / fulfilling on the request - as this would in Hornbill terms need a Service Manager subscription.   

This is why i am keen to understand the expectations of the division managers in this example?

In the meantime a possible solution would be as follows:

1. Capture the data breach information in progressive capture

2. Inject this information into the summary / description or custom fields of the request

3. Add the division managers as connections

4. Automatically (or manually) email the division manager's an email template containing the information the need to view or comment on

5. They can email back any questions / actions to the Incident which can be actioned by the support team who own the Incident 

6. The automated emails to the connections can be built into the supporting business process at the required touch points, not forgetting you can now use custom questions on the Incident tasks, and the task outcomes to these questions can be injected into request custom fields and emailed to the request connections via email templates. 

Thanks

Steve

Thanks @Steven Boardman 

I'm actually already doing the solution you've suggested - good to know my thinking is the same!

I'll try my best to describe the process so you can understand the requirements here...

If a member of staff detects a data breach they must log it via a catalog item on the portal, this then gets automatically assigned to our Data Protection team (who have Service Manager licences) as an incident. The Data Protection team then manage the Data Breach through the BPM, completing tasks, etc.

The division managers (Basic users) must review the data breach with the person responsible for causing the breach, updating it with any emerging information and relaying this to a governing body. In most cases the person logging the breach isn't the person who caused the breach, this is where the current restriction causes problems. If the division manager isn't a line-manager of the person logging the breach they are unable to view it in the portal.

Hope this explains it?

 

 

[Steven Boardman]

@dwalby thanks for the explanation

If the person who reported this is unlikely to be the person who caused the breach, is their interest in this request limited to only wanting to know if this has been resolved? if so perhaps you could consider the following workaround?

1. On receipt of the data breach report and the investigation to conclude who caused the data breach, the person causing the breach could be changed to the customer on the request, thus allowing their line manager (division manager) to view the request on the portal along with them.  

2. The reporting user could be 'demoted' to a connection and they can receive email communications to inform them as such and it's been dealt with - in effect the same type of action as closing the request down for them.

I appreciate this is a workaround and may not work but i thought it was worth suggesting. 

We still have the requirement to work with connections visibility and as this progresses we will post back here

Steve

[Michael Sharp]

+1 on this

[dwalby]

@Steven Boardman I think this subject was discussed at Insights 19 as an upcoming feature - is there a timescale on when it'll be available, or a setting to enable it?

[Steven Boardman]

@dwalby indeed a popular new feature we shows at INSIGHTS 19, this will be available in the next Service Manager update which is due out shortly.  You will need to enable this via a system setting to use it, and it will need to be enabled per service / request type and connection type as fits your needs.  It will be visible in the request list on the current Employee Portal (my services) and then on the new Employee Portal / Pages / Service Catalog on their release (Which was also show cased at INSIGHTS).

[James Ainsworth]

The feature for providing a view only access to a request for Connections is now available.  The view only access of a request is only available to full Collaboration Users and Basic Users.  These requests can be accessed under the My Services option within the Hornbill Client.

 

More information about this feature can be found here. 

Regards,

James

[Giuseppe Iannacone]

@James Ainsworth & @Steven Boardman this is very appreciated, please report my gratitude to the whole team