One way we have gotten around some of these issues was to create a Global Company, separate from the OOB Global Company. We use this group for global services. You can also setup Parent/Child companies that will limit the number of companies being pushed to the permission fields. We were running into a lot of issues once we passed I believe 20 companies. Anything under that worked fine. Anything over we had to start making some changes on the backend. The Services CI is definitely a huge creator of the problems, which is what I'm sure you are seeing in SRM. Getting the Parent/Child functionality to work is not a small task. However, it is not overly difficult. This way you keep your groups associated to service fairly small and should have no issues with the OOB functionality.
On Thu, Aug 2, 2012 at 11:09 AM, Terry Bootsma <[email protected]>wrote: > ** ** > To expand on Carl's note below, I've also used this approach for Service > Request Definitions. > > But beware, with a large number of companies, the Field 112 on the SRD has > a limitation of 255 chars. There is also the issue of updating each SRD > every time a new company comes on board. > > To alleviate this, consider creating a Computed Group in the Group form > that has it's definition include all the GroupIDs of the companies as an > "OR" qualfication. Then, include this single Computed Group name in each > SRD's field 112 ( You can get access to this field via the Form "Service > Request Definition Base"). > > Using this approach, each time you add a new Company, all you need to do > is update the Computed Group definition in the Group Form and, voila, the > Company has access to all SRDs. (of course, when you update the Group > schema, the server re-caches, but you would have gotten this when you > created the Company anyway). If you use Entitlements, you will also have > to manage this as well, but there are People Qualifications that you can > use to make this easier. > > Hope this helps... > > Terry > > > > > ------------------------------ > *From:* Action Request System discussion list(ARSList) [mailto: > [email protected]] *On Behalf Of *Carl Wilson > > *Sent:* Thursday, August 02, 2012 5:12 AM > *To:* [email protected] > *Subject:* Re: Configuring companies and multi-tenancy > > ** > > Hi Tauf,**** > > although this is true, a Global SRD cannot have a template, you can > configure the base SRD form to display by updating field 112 to the Group > ID's for the required Companies or make it Public so that all users can see. > **** > > This way you can create a normal Template based SRD and expose it outside > the Company it was setup for. It is a workaround that is done via > configuration though, not customisation.**** > > ** ** > > Cheers**** > > Carl**** > > ** ** > > http://www.missingpiecessoftware.com/**** > > ** ** > > *From:* Action Request System discussion list(ARSList) [mailto: > [email protected]] *On Behalf Of *Tauf Chowdhury > *Sent:* 02 August 2012 10:03 > *To:* [email protected] > *Subject:* Re: Configuring companies and multi-tenancy**** > > ** ** > > ** **** > > Brian,**** > > The one thing I've had trouble with is SRM. There is a limitation there I > believe in that a Global AOT can't have application templates associated to > it because they are company specific. So, all the fields would have to be > mapped manually. This adds major admin overhead if configuring services > that would be global and available to more than one "sub-company."**** > > Just one more thing to look out for. > > Sent from my iPhone**** > > > On Aug 2, 2012, at 2:28 AM, Brian Pancia <[email protected]> wrote:**** > > ** **** > > Jose,**** > > **** > > I have setup systems with well over 100 companies. One thing to look out > for is there is a limitation on your access fields on CIs. Depending on > the number of companies and how many companies use a Service you may need > to change a couple fields to get things to work.**** > > **** > > If you look at your org, you are probably split into multiple branches > that have multiple divisions under them. You can setup a Parent Company > for each branch and have a Child Company for each division. IT may be one > branch, possibly the OCIO, with multiple divisions (Net Ops, Security, Data > Center, etc.). Each division in IT may have multiple support groups that > support one or more branches/divisions throughout the organization. > Support Groups can support multiple companies. So let’s say you have a > Company Data Center, which is a division under the OCIO. The Data Center > company has a Support Group Server Administrators under it. Server > Administrators can support multiple divisions/companies. Now you have > Server Sam that is a server guru for your HR Division/Company. You can > give Server Sam permission to the HR Division only and they would only see > the HR tickets for the Server Administrators. The problem is that since > Server Sam now has rights to the HR Division he will see all HR Division > tickets, because out of box the customer company is listed in field 112. > You can exclude Server Sam from the HR Division and he will see only HR > Division tickets assigned to him because I believe Assignee has access to > tickets. I have to double check but I don’t believe Assignee Group has > access to tickets, so Server Sam would not be able to see all tickets > assigned to the Server Administrators. I might be off on Assignee Group it > has been a few months since I looked at that.**** > > **** > > So the problem comes into play with your lock downs. Look at field 112 > and there is another field called something like Vendor Assignee Group. > Also look at your Request ID field which controls your lockdowns. Based on > your rules you may be able to build a simple filter to reset field 112 to > provide lock downs beyond the Company level.**** > > **** > > The problem with changing Company names is pretty easy. The data > management tool allows you to update Company names and actually does a > pretty good job.**** > > **** > > Services are a CI and there are challenges with the rowlevelsecurity > fields character limitation. There are a few other places you may run into > this when setting up a large number of companies. I believe the Consoles > is one area. I’d have to check some of my old notes. Essentially Services > can be used by and support by a number of different companies.**** > > **** > > Hopefully this helps. I believe I’m slated to give a presentation at > WWRUG on this very topic, which will go from very basic single tenancy > setup to complex with multiple companies and row level access based on > building access control lists. I’ll also talk about Parent/Child groups > and how to set those. The fields are there in the group form to support > it, but the functionality is not. It’s pretty simple to build that > functionality out though to be supported within the ITSM Suite. The best > thing you can do is start off pretty simple because if things aren’t setup > properly and too complex some of your tickets may go into a black hole. > Most IT tickets don’t need to be lockdown. No one cares that the HR > departments printer is not working. When you get into Security, PII, and > Financials that’s a different story.**** > > **** > > Good Luck,**** > > **** > > Brian**** > > **** > > **** > > *From:* Action Request System discussion list(ARSList) [mailto: > [email protected]] *On Behalf Of *Jose Huerta > *Sent:* Thursday, August 02, 2012 1:12 AM > *To:* [email protected] > *Subject:* Re: Configuring companies and multi-tenancy**** > > **** > > ** He, he..**** > > **** > > Well, I'm talking of a regional government of a province with a population > of half a million people. > > And, It isn't USA.**** > > **** > > Regards,**** > > **** > > Jose**** > > **** > > On Thu, Aug 2, 2012 at 12:15 AM, Goodall, Andrew C <[email protected]> wrote: > **** > > ** **** > > Now I know where all our tax money is going J - not a surprise!**** > > **** > > Regards,**** > > **** > > *Andrew C. Goodall***** > > Software Engineer**** > > Development Services**** > > [email protected]**** > > *jcpenney***** > > 6501 Legacy Drive**** > > Plano, TX 75024**** > > jcp.com**** > > **** > > *From:* Action Request System discussion list(ARSList) [mailto: > [email protected]] *On Behalf Of *Jose Huerta > *Sent:* Wednesday, August 01, 2012 4:58 PM > *To:* [email protected] > *Subject:* Configuring companies and multi-tenancy**** > > **** > > ** I have an special case, and I know that there are a lot of solutions. > But I want to hear from you, experts, what's your opinion.**** > > **** > > Here's the case:**** > > **** > > **** > > A public administration has 10 divisions (Transport, Healthcare, Security, > Employment, ...)**** > > **** > > The IT service is organized in two tiers. First there is a list of > corporate services, that all divisions receive. Second, each division has > it's own set of proprietary services.**** > > **** > > The Service Desk is divided in divisions, so each division has it's own > service desk. support groups for corporate services attend incidents from > all service desks.**** > > **** > > A lot of services are provided by external companies, totally integrated > in the structure, where the external employees work in-house. Each couple > of years the provider can change, being another company the one that > provides the same service. This is transparent for the rest of the > organization.**** > > **** > > Each division has it's own set of management.**** > > **** > > Well, How would you map the companies?**** > > **** > > My first approach was to have a company for each division, since it is > desirable to have a security layer between divisions (Healthcare managers > don't need to see about Employment). Also I created another company for > corporate services, where all people working on this IT office is inside > another company.**** > > **** > > The problem arises with services were people are form external companies. > For instance the email. The email server are property of the public > administration. Also the manager of the service is a public employee. But > all technicians are from an external company that is providing the service. > It is desirable that the support group would be inside the division. But > also would be desirable to have these people on another company so they > only see tickets assigned to them (and can¡t spy another services provided > by another companies).**** > > **** > > For the e-mail service case:**** > > SOLUTION A:**** > > **** > > All external people are integrated inside the company "IT Office" and the > support group is "IT Office/Corporate Services/Email".**** > > **** > > PROBLEM: Those people can see every corporate ticket.**** > > **** > > SOLUTION B:**** > > **** > > All external people are inside a new company with its own name "Lilonti". > But the support group is IT Office/Corporate SErvice/Email".**** > > **** > > PROBLEM: If I don't provide access to the IT Office company the Lilonti > people can't access tickets assigned to them.**** > > **** > > SOLUTION C:**** > > **** > > All external people are inside a new company with its own name "Lilonti". > The support group is created inside this company "Lilontly/Corporate > Service/Email".**** > > **** > > PROBLEM: If the provider changes, we need to change all assigment rules, > templates, etc. Because the support group changed.**** > > **** > > **** > > **** > > Any Idea? **** > > What would you do?**** > > **** > > **** > > **** > > Jose M. Huerta > Project Manager**** > > Movil: 661 665 088**** > > Telf.: 971 75 03 24**** > > Fax: 971 75 07 94**** > > <image001.jpg> <http://www.sm2baleares.es/>**** > > SM2 Baleares S.A. > C/Rita Levi **** > > Edificio SM2 Parc Bit**** > > 07121 Palma de Mallorca**** > > > <image002.jpg><http://es-es.facebook.com/pages/SM2-Baleares/158608627954> > <image003.jpg> <http://twitter.com/#!/SM2Baleares> > <image004.jpg><http://www.linkedin.com/company/sm2-baleares> > **** > > La información contenida en este mensaje de correo electrónico es > confidencial. La misma, es enviada con la intención de que únicamente sea > leída por la persona(s) a la(s) que va dirigida. El acceso a este mensaje > por otras personas no está autorizado, por lo que en tal caso, le rogamos > que nos lo comunique por la misma vía, se abstenga de realizar copias del > mensaje o remitirlo o entregarlo a otra persona y proceda a borrarlo de > inmediato.**** > > P Por favor, no imprima este mensaje ni sus documentos adjuntos si no es > necesario.**** > > **** > > _attend WWRUG12 www.wwrug.com ARSlist: "Where the Answers Are"_ **** > > > The information transmitted is intended only for the person or entity to > which it is addressed and > may contain confidential and/or privileged material. If the reader of this > message is not the intended > recipient, you are hereby notified that your access is unauthorized, and > any review, dissemination, > distribution or copying of this message including any attachments is > strictly prohibited. If you are not > the intended recipient, please contact the sender and delete the material > from any computer.**** > > _attend WWRUG12 www.wwrug.com ARSlist: "Where the Answers Are"_ **** > > **** > > _attend WWRUG12 www.wwrug.com ARSlist: "Where the Answers Are"_ **** > > _attend WWRUG12 www.wwrug.com ARSlist: "Where the Answers Are"_**** > > _attend WWRUG12 www.wwrug.com ARSlist: "Where the Answers Are"_ **** > _attend WWRUG12 www.wwrug.com ARSlist: "Where the Answers Are"_ _attend > WWRUG12 www.wwrug.com ARSlist: "Where the Answers Are"_ _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug12 www.wwrug12.com ARSList: "Where the Answers Are"
