Protal adoption for different departments

Andrius_Svirskas

My boss after seeing Cireson portal screenshots asked us to implement HR and later possibly Finance departments onto Cireson portal, but anywhere I've looked, its not something that is doable. at least not without additional management server and Cireson portal. Have anyone done something like this or similar? we are currently on SCSM 2012 and have 2016 on standby until I have solution

thanks

Brian_Wiest

What is your goals of adding HR and Finance? 
By reading the "not something that is doable", can only guess that you are referring to keeping the groups separated from the IT departments. 
If so there are a number of ways to accomplish this, it depends on your requirements. 
You could do it by omission or by strict security scoping of the work items.
I have 40 support desks in my environment. Each desk I use the console and portal support group mappings to map them to their support requests (omission) where if they search they can see all requests in the system but that is not an issue for the environment.
The other strict you would setup Queues and Groups then apply security roles for each use case (department).
HTH

Jonathan_Boles

We've accomplished this feat in our organization but due to security implications, we're using completely isolated SCSM environments. While it is possible to lock the data and requests down to different groups to some extent there are several gaps and pain points that were simply too risky, we found this was the best solution in the long run.

Adam_Dzyacky

Second @jonathan_boles and @brian_wiest - this is entirely doable and I've also performed this with several departments. However its generally not the first thought when deploying SCSM since its viewed on the outset as an IT tool. In which case I tend to see a lot of orgs deploy it, give IT essentially blanket admin access (sans one or two things maybe) and then don't understand how to "roll back" into segmented permissions and groups so as to satisfy the request to get more departments involved. Suffice it to say, it's some rework but it isn't difficult once you start understanding how permissions get calculated in SCSM. Not to mention, once its done it's a process you can quickly repeat for the onboarding of new departments.

This said - it all starts with creating Queues for Support Groups and defining those permissions so that IT can only see Incidents, Service Requests, etc. that are assigned to IT based groups. This is really the fundamental basis of permissions, as you can now repeat the process for Human Resources, Finance, etc. Giving each of them their own unique queue scope and working on the same platform, but entirely independent of one another. Now you can create templates, requests, etc. that only those teams can see. HR can see HR only requests. IT can see IT only requests, etc. etc.

Following this is where you can start getting creative about what permissions can see multiple queues which in turn allows a Work Item to be worked across several teams. The most popular example of this would be a New Hire request (easily affects IT and HR). Here as an example, you could create a Queue of Service Requests with a Support Group of "Human Resources" and contains the title of "New Employee". This queue would get assigned to IT and HR analysts allowing them both to have visibility on the work item, but still keeping the rest separate.

Andrius_Svirskas

thank you all for replies, and sorry for not explaining exactly where I've stuck and apologies if questions are something very obvious as I only know SCSM basics. I do understand that all achievable by queues and groups, but, as example, how to setup reply from email for different "departments" so if user decide instead of finding correct email for service request/incident reports delete subject and  reply to default service desk address? email will go to main queue ( in our case IT service desk)

thanks

Jonathan_Boles

Hi @Andrius_Svirskas, unless someone has figured out an epic workaround, the only way to use multiple outbound email addresses would be through using Orchestrator to completely replace the out of box SCSM notifications. This limitation along with reporting were some of the main reasons we had to go the route of completely independent SCSM environments for our departments.

Adam_Dzyacky

I think I can speak for everyone here when I say none of us woke up with this knowledge @Andrius_Svirskas
(although it would have made things terrifically simpler!)

If you're looking to handle multiple email channels to segment how requests come in I see two options:

1. You'll have to perform a lot of customization with Orchestrator
2. You must move your organization away from email towards a portal first mentality

That second one is not only an initiative in and of itself (since it's generally a huge culture shift), a workaround to the first point, but one that can be accomplished as you begin creating requests for other departments. What's more, it introduces the need to generalize the SCSM Email to be something less IT and more organizational. In which case, the org begins to adopt the mentality that "everyone is a part of this thing" and its not just IT.

Brian_Wiest

Ah you are running into the same thing I have to "work around"

See https://community.cireson.com/discussion/1949/advanced-email-notification-connector#latest where I am hoping for a new feature from Cireson to allow to specify outbound email notifications based on support group.

In the mean time what I have is a Catch All generic box for all email traffic.
Yes we have a "small" variance when people submit new requests to the workflow box but 90% of the time not an issue. 
Then I have Email boxes setup for each support group for new work requests. each mailbox has a different template to match that support group.
Along with this each support group has a branded email.
The end result everything comes from brand@domain.com
But if someone wants to start a request they use the portal service offerings or the specific brand-hr@domain.com email box. 
HTH

Andrius_Svirskas

thank you all for replies, will have to wait and see if Cireson team can build feature as requested by Brian_Wiest. please correct me if I'm wrong, but if I understand correctly, same as with outbound email, there is no option to customise SR and IR prefix to match queue/department, for example IR for HR would have prefix HR-IR  and IT would have IT-IR (or something similar)

Brian_Wiest

You are correct, work item prefix cannot be scoped to support queue out of the box. but guess since it is just a value in the SQL table you could runbook it to update to the needed value. 
For my environment everything is branded as a support portal and the HR, IT, and budget teams all work in the same structure as there are a number of cases that work will transfer between the groups.