[Advice needed] - Scoping the portal for different branches in an organization
Gabriel_Lences
Customer Advanced IT Monkey ✭✭✭
Hi all,
We'd like to get some advice, opinions or best practices going for a certain somewhat topic : scoping the ro forms for different branches in an organization. Let me elaborate: we have branches in a more than few countries in our organization - US, UK, Germany, Japan, Italy, Australia, Singapore, Poland, Czech Republic, Slovakia, Romania, etc. You get the jist by now :)
The struggle:
As of now only our HQ (Slovakia) and our Germany branch is currently actively using our portal. Currently, we are in the process of adding more of our branches to the portal, UK, US and more will follow. As you might know where this is headed, we want to have "customized" views of RO's for each country, otherwise the portal will just be a huge mess. Currently our germany branch is using our "HQ" version of the portal meaning they have no "customized" fields for them in the RO's. If our german colleagues want to add something for them to the ROs, we add that in, but then our HQ users can see that as well, so it's complicating things a bit. As scoping for RO's is not yet a thing ,we have several solutions and ways we can solve this ongoing issue for us.
A lot of our RO's can be applied globally accross the branches, but some really do require personalization , so keep this in mind while reading the next paragraph. (In other words, we just need to create personalized RO's , not whole SO's)
Possible solutions we figured out so far:
#1 - Duplicating Service Offerings (SOs)
This is the first - probably one of the easiest things we could do but also the messiest. Imagine a SO containing 10 RO's. One of our branches decides that they need to have 1 extra field / dropdown / whatever in only 1 of the RO's. We have to duplicate the whole SO just because we need to add one extra field to an RO and then scope the first and the second SO. Ugh. What a mess this would make over time.
Not to mention our Service Desk and creating tickets on behalf of someone. We are heading in the direction of having 1 global service desk (sitting in one place) , so the SD would need to have basically every version of every SO in our portal if we wanted them to be able to create the "customized ROs" for every country and this would just look absolutely AWFUL on the homepage of a SD analyst with all the duplicate SO's. Other option would be to have the local IT's to only have the privilage to create the personalized RO's on behalf of someone, but then the "global service desk" concept, to which we are heading falls apart.
#2 - Using custom javascript
We don't even know if this would be somehow possible or not, but we were brainstorming today with @Peter_Miklian that maybe some custom.js would work that would catch the logged in users location (can this even be done?) and according to that it would only show them their own custom RO's. Bear in mind this would mean we would need to duplicate the RO's, which isn't as bad as duplicating entire SO's i guess, but it would probably require an abnormal time of developing the .js code for it to work reliably.
#3 - Leveraging the dynamic fields of ARO's
We are using ARO's in every RO in our environement. This is probably the cleanest and simplest solution where we could create customized input forms for only RO's that would need them. Basically the way this would work would be
1st input = Choose the country for your service
while providing a list of the branches that have customized input forms in the RO and then it would roll completely different forms based on this selection. While this probably is the cleanest way we could think of for the end users, service desk and analysts alike, it has the downside of having A LOT of inputs in the ARO setup in the backend but we are fine with this as long as it works. The other downside of this is the fact that all users will still be able to see all RO's (remember, the customization would take place only after the user clicks the RO itself and gets to the input form) despite some RO's being completely country/branch-specific, but i guess we would be able to live with this as well, if there's no neater solution.
So my question is:
Which of these do you think works in the best way without ending up with a mess? Also if you have any other / better suggestions on how we could work out this difficult situation, please let us know, any help is much appreciated!
Thanks a ton guys,
Gabe
Comments
Are you saying that as a user in say Australia when I complete a RO, my request gets routed to the Australia support desk?
Not exactly. A user in Australia for example should be able to see the global RO's that are the same for every country and their country-specific RO's (or their customized input forms) and while this would get routed to an Australian support group, the vision for our service desk as I mentioned is to have only 1 service desk sitting in HQ (Slovakia) so this HQ Service Desk should also have the access to the "Austrialan-customized" portal RO's in case they needed to create their version of the RO for someone else.
Hopefully this makes sense 😄🤷♂️
I am not quite sure I am following but here is what I am facing in my environment.
We have one enterprise support desk for all routing, but they are tasked with only accepting requests from level one support. They route work to 14 other enterprise support desks, whom also have sub desks. For the level 1 desks we have just under 100 for all the different physical offices. The user community is suppose to reach out to the level 1 desk to start all requests.
So I was faced with the challenge of getting user X request to their local support desk without having to create an RO for each local support desk.
We also have the challenge of there are so many assets in the environment that when a user goes to report a hardware issue and we present them a query picker the default picker cannot return the results due to the AD 5K limit. So we always have to introduce a question before to filter the list relevant to the user.
How we addressed the challenges.
For the 5k limit we utilize the organization CI class we get with Cireson asset management, we created an organization for each of the physical offices and present that as a first choice query picker that then filters the hardware query picker. Think Australian as a organization showing Australian assets. Now we do not allow the level 1 desks to have customization but you could leverage that as well showing hidden prompts if a specific organization is chosen.
For the support group mapping, we have all new requests for these RO's get dropped into a holding support group. (only a few admins are in this group to monitor for stuck items) We have a Orchestrator runbook that checks for any item in this holding support group, when it finds one it looks at an attribute of the affected user and assigns to the local support desk. We did have to play with timing due to having notify analyst enabled but it does allow us to have one RO that routes work to the ~100 different level 1 support desks.
HTH
@Gabriel_Lences
personally I would go with a combination of #2 and #3, with either an expanded field in the user class, or relationship to the location or organization if you have asset management.
I would combione the same requests into a single request with a selection for whic country they are in, being the organisation/location or extra user field, which then controls what prompts show on the aro form.
when opening the home page you could do a quick check with javascript to check where the user is, and remove any request offerings they should not be able to see at all. You could use javascript to remove any country specific requests from the home page for those that should not see them.
on all aro forms run some javascript which checks if the country selection field is present, and if it is hide it and automatically fill it in with the users location, so that they do not require to select it themselves and get all the prompts they are meant to see.
We use Orchestrator to route to the correct Support group based on the users location and if the user is a staff or student. You can use some user AD propperties or like we do ask the user where he is currently located and route it to the required support group.
To restrict asscess to ROs I created catalog groups and scoped the end user roles to specific CGs
Hi guys, thanks for all the inputs. My post wasn't really to cover Support Group routing, rather than how to get behind the obstacle of non-existant RO scoping based on country / branches (how to provide some country-specific variants of certain ARO's - eg. requesting a new computer might have different inputs in our DE branch than in our UK branch etc.) and how to most painlessly achieve this.
We'll probably go with option #3 now and will try to later combine it with some custom js as @Jeff_Lang mentionted.
@Gerhard_Goossens we have this as well, so we have our DE catalog group and our HQ catalog group for now but this doesn't get around the fact when we want to have the same RO for both (let's say a new computer request) but with different fields in the input forms based on countries / branches in an organizationa. That's the point I was trying to make on how to best get around this :)
Thanks for all the suggestions so far, if anynone has any more ideas feel free to drop them in here or upvote the RO-level-scoping for portal :)
Just had a quick talk with one of our website devs regarding this approach, she said that's it's a really messy way of doing it. @Jeff_Lang could you possibly maybe provide a sample .js code of how this would work? I expected it would work somehow along the way of "get a users country / location through some API call and if the users location / country = e.g Germany show RO's containing Germany in their internal notes field for example". But our dev couldn't find an api call to grab users location and couldn't figure out how this would be linked to displaying / hiding certain RO's. She described it something along the way of combining frontend with backend functionality which might be really difficult to pull off...
Thanks in advance.
G.
@Gabriel_Lences
The specific code used really depends where you are storing the location/org area etc in service manager.
if for example you are just putting the country/Department etc into AD and then want to use that for this, the following will get that information about the logged on user, and you can just add the code to modify/show/hide elements on the page inside the success block
$.ajax({
url: "/api/V3/Projection/GetProjectionByCriteria",
data: JSON.stringify({
"Id": "90bc5c2b-c7b9-71f3-a4d8-3acaa565f9ab",
"Criteria": {
"Base": {
"Expression": {
"And": {
"Expression": [{
"SimpleExpression": {
"ValueExpressionLeft": {"Property": "$Context/Property[Type='10a7f898-e672-ccf3-8881-360bfb6a8f9a']/UserName$"},
"Operator": "Equal",
"ValueExpressionRight": {"Value": session.user.UserName}
}
}]
}
}
}
}
}),
type: "Post",
contentType: "application/json; charset=utf-8",
dataType: "json",
success: function (data) {
console.log(data[0]);
console.log(data[0].Country);
}
});
but if you are using another class that is related to the user class in scsm then you could create a type projection that just has the user class and the linked class that you are getting the location etc from, and replace the "ID" in the above with the type projection ID.