[Advice needed] - Scoping the portal for different branches in an organization
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 :)
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.
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,