Data access via different groups only

[Ashley]

Is it possible to restrict access to SR, RM, CH tickets based on teams/organisations?

I know you can set up filters at the Request List and share them with teams and individuals, but this doesn't stop the teams from viewing, searching and editing other data not relevant to them.  May be the Service Portfolio has some relevance here, but I don't want to set up new services for different teams.

 

Any advise would be much appreciated.

 

Thanks

[Steve Giller]

Each Request Type has related Service Manager Roles, e.g. Service Request Assignee, Service Request Full Access, and Service Request User - removing these roles should hide the related type.

However, there are additional Roles that will supersede these, possibly Service Desk Manager, without checking, so the correct way to manage who has visibility of which Requests is to configure the Supporting Teams correctly within the Service Portfolio

[Ashley]

Thanks for the reply.

Just to be clear under Service RELEASE I have release types Fincore, Battlecat, etc.  So can I restrict

 data visibility within the service by teams.  I'll review the roles.

 

Thanks

[Ashley]

New TEST account for Battlecat

 

Testing with new Hornbill login BCTEST.

 

 

Roles

 

Roles as below:

 

 

Team

 

I have also set up a new team Battlecat and added BCTEST to that only:

 

 

 

At login using BCTEST get portal and selecting Request List get:

 

 

 

 

Have shared only two filters as below:

 

 

And the below is listed as it should:

 

From the All My Services all accept All My Services are blank so that is good confirming they can’t see anything there.  However, All My Services shows just that, all tickets for Change and Release.  I believe that is because the login have the Release role, although not Change, so possibly not as both Change and Release tickets are listed.

 

 

Next step is to review Service Portfolio and adjust further there to restrict access:

 

 

Been advised:

‘Each Request Type has related Service Manager Roles, e.g. Service Request Assignee, Service Request Full Access, and Service Request User - removing these roles should hide the related type (done this).

However, there are additional Roles that will supersede these, possibly Service Desk Manager, without checking, so the correct way to manage who has visibility of which Requests is to configure the Supporting Teams correctly within the Service Portfolio’

I have been looking for teams in the Service Portfolio and don’t understand where to adjust teams?  

Any advise would be much appreciated please.

 

 

 

[Met]

Click into the service in the service portfolio then define which teams support it:

Once one or more are added, only those in that team will be able to view the requests.

[Ashley]

Tried this and just stops any team not added to the portfolio from accessing that service.  Ton be clear I need the team Battlecat to access the Release Management and Change Management services, but only allowed to see Battlecat relevant changes and releases.  As say I have got two filters to list just Battlecat, but they need to access RELEASE/CHANGE services to see that and only that.  If they select all services then they will see all release and change tickets regardless.  So is there a way to do this?

[Met]

I imagine you'll need to separate out the different types of changes and releases into separate services, so you can then restrict visibility to appropriate teams. As far as I know, there isn't a more granular way of restricting visibility of tickets in the same service.

[Steve Giller]

1 hour ago, Ashley said:

So is there a way to do this?

The short answer is - have a Battlecat Change and Release service. Or Battlecat Change and Battlecat Release services. These will be separate from the other Changes/Releases.
Then add your Battlecat team as a Supporting Team - if another Team (e.g. the Service Desk) need to see the Battlecat service(s) add them too - this will give the Service Desk visibility without giving Battlecat any additional services to view.

 

[Ashley]

Ok but then surely I'd have to set up separate BPMs, etc for

Battlecat.  I have menu options under release for all types of release including Battlecat.  Even if I could share this with the new service Battlecat they would then get the other type of release options from release.  Sounds like I would need to separate BPMs, data capture from release service to release Battlecat service and at this point in time would not be feasible with the amount of time spent getting this set up before I found Battlecat was to be added.  Also any new release type added in the future if data security was key then again I'd have to have a new service, new BPMs similar to other. BPMs, but suited to new release types.  Currently keeping to one Release service allows me to add new release types with minimal effort and use the same BPMs for all release types without having to recreate BPMs from scratch.  Much more efficient.  Is there not a way under All my services option to not Allow this option to display?  Then having my two shared filters for Battlecat data would possibly be sufficient (or not have the option for teams, service hidden some how?).

[Ashley]

I would rather use the same service Release, but make it such that any other option for Data capture is greyed out and can only select Battlecat for release creation.  For Change this is more complex as is shared by all for creating changes and is differentiated from other changes by Battlecat selected for certain fields like provider, etc.

I'm guessing there is no easy way to mask out data creation options so that only certain users can access (not by service, but within the service).  Same for Request list apart from using filters.  As say in the Request list having the selection for teams, my services greyed out so can't be selected would be helpful.

I am not up for a complete redesign, as this is well and truly in use now, so future enhancement to restrict data access and data capture within a service would be a useful improvement.  Also as say by having multiple services to cater for separate team access would require duplication of effort both for data capture and bpms.  So is not an effective solution.  Again also for future release type additions for other companies again emphasises new services is not an efficient solution 

 

 

[Ashley]

I've created a new Service called Release Battlecat as below, but I don't see it listed when I am in Request List and select Raise New...  It's basically the same as the Release service I've been using, but name is different.  The Intelligent Capture & BPM are the same.

 

 

 

 

 

What am I missing?

 

Thanks

Ashley

[Steve Giller]

On 8/12/2023 at 8:49 PM, Ashley said:

I've created a new Service called Release Battlecat as below, but I don't see it listed when I am in Request List and select Raise New...

Are you a member of the Battlecat Team that supports it?
If not, have you specified a Customer who is subscribed to that Service before trying to select it?

It may be useful to have an engagement with Expert Services to go through this in a targeted education session rather than picking it apart one step at a time on the forums.

[Ashley]

As below.  I added Release Management, which I'm a member of to support.

 

Yes I tend to agree this was done by Bob Dickinson when we first had Hornbill set-up.  So not too familiar with Service set-up to be honest.  Also others are asking I hold back in my company as not sure if this is the way forwards either.  May just stick with the Release Management service and Battlecat to use it with the rest of us.