RE: Support Group Structure Recommendations

[Joel D Sender]

Sounds right!

Each of the 3 would get the notices for their own group, but have security
access to all 3 groups.

 

Joel

Joel Sender  *<mailto:jdsen...@earthlink.net> jdsen...@earthlink.net  

 

From: ARSList [mailto:arslist-boun...@arslist.org] On Behalf Of Lippincott,
Levi (OMA-GIS)
Sent: Monday, June 4, 2018 12:16 PM
To: ARSList
Subject: RE: Support Group Structure Recommendations

 

Joel,

 

So in theory we could set it up that the local IT support at their specific
offices could be members of their local groups and have a group setup above
them all as the Parent and add the non-local people to so they would receive
access to the tickets but not be bombarded with the notifications?

 

So something like this:

Sub Parent Central Region Group

Local Group A

Local Group B

Local Group C

 

Then we added people, let's say Jim, Barb, & John, in the following setup:

SPCRG: Jim, Barb, John

LGA: Jim

LGB: Barb

LGC: John

 

Then they would all have access to each other's queues but they would only
receive notifications for the respective locations?

 

Did I understand that correctly?

 

Levi Lippincott / Associate Remedy Developer

 

+1 402 561 7014 office

+1 402 321 5421 mobile

 <mailto:levi.lippinc...@interpublic.com> levi.lippinc...@interpublic.com

 

Interpublic Group  6825 Pine Street, Omaha, NE 68106

 

"Talent is a Gift; But Character is a Choice." -Matt Grotewold-

 

From: ARSList [mailto:arslist-boun...@arslist.org] On Behalf Of Joel D
Sender
Sent: Monday, June 4, 2018 1:16 PM
To: 'ARSList' 
Subject: RE: [EXTERNAL] Support Group Structure Recommendations

 

Levi,

Hierarchical groups allow 'parent' groups to include other groups.

All the 'Sub # - Company 2' groups could be collected into a 'parent' group,
across Tenant Companies.

For example, if each 'company' had a separate HR group, a master HR group
could include them all.

 

That notices only going to regular (non-collector) groups is actually a
feature; a member of a collector/parent group could be buried in notices.

This is especially true if you combine collector groups into larger
collector groups; i.e. regional HR groups into a top-level company HR group.

If someone needs the notices, put them in that regular group.

 

Let us know how you decide to proceed.

HTH,

Joel

Joel Sender  *<mailto:jdsen...@earthlink.net> jdsen...@earthlink.net  

 

From: ARSList [mailto:arslist-boun...@arslist.org] On Behalf Of Lippincott,
Levi (OMA-GIS)
Sent: Monday, June 4, 2018 9:56 AM
To: 'arslist@arslist.org'
Subject: Support Group Structure Recommendations

 

Hello ARSList!

 

I work for a company that has several companies it owns which in turn own
many companies themselves which translates to several hundred companies
around the globe.

 

Think of the company structure as:

Main Company

Sub Company 1

Sub-1 Company 1

Sub-1 Company 2

Sub-1 Company 3

Sub-1 Company 4

Sub-1 Company 5

Sub Company 2

Sub-2 Company 1

Sub-2 Company 2

Sub-2 Company 3

 

Our local IT support often handles support for multiple companies, typically
under the same sub parent company though sometimes they can handle multiple
sub parent companies at the 1 or several sites throughout a city. So for
years we have operated under a model where our local support group policy
has been 1 group per city per company.

 

This has served us well up until more recently. Now we have several local IT
support teams that are providing support for larger sub parent companies and
they are now supporting multiple cities which has led them to be a member of
50+ support groups. This is creating a performance issues when loading &
refreshing their Incident Management Console.

 

Our other challenge is we have one helpdesk that relies heavily on the
custom assignment rules to be able to send tickets to the correct location's
local support when they need to escalate an incident to a field tech.

 

So we have been considering different methods to structure these groups in a
way that we can minimize the number of groups they belong to, to increase
performance, but we keep running into the challenge of those assignment
rules becoming complex and hard to manage.

 

We just upgraded, a couple weeks ago, from 8.1.00 to 9.1.04 and I've just
become awa

RE: Support Group Structure Recommendations

[Lippincott, Levi (OMA-GIS)]

Joel,

So in theory we could set it up that the local IT support at their specific 
offices could be members of their local groups and have a group setup above 
them all as the Parent and add the non-local people to so they would receive 
access to the tickets but not be bombarded with the notifications?

So something like this:
Sub Parent Central Region Group
Local Group A
Local Group B
Local Group C

Then we added people, let's say Jim, Barb, & John, in the following setup:
SPCRG: Jim, Barb, John
LGA: Jim
LGB: Barb
LGC: John

Then they would all have access to each other's queues but they would only 
receive notifications for the respective locations?

Did I understand that correctly?

Levi Lippincott / Associate Remedy Developer

+1 402 561 7014 office
+1 402 321 5421 mobile
levi.lippinc...@interpublic.com

Interpublic Group  6825 Pine Street, Omaha, NE 68106

"Talent is a Gift; But Character is a Choice." -Matt Grotewold-

From: ARSList [mailto:arslist-boun...@arslist.org] On Behalf Of Joel D Sender
Sent: Monday, June 4, 2018 1:16 PM
To: 'ARSList' 
Subject: RE: [EXTERNAL] Support Group Structure Recommendations

Levi,
Hierarchical groups allow 'parent' groups to include other groups.
All the 'Sub # - Company 2' groups could be collected into a 'parent' group, 
across Tenant Companies.
For example, if each 'company' had a separate HR group, a master HR group could 
include them all.

That notices only going to regular (non-collector) groups is actually a 
feature; a member of a collector/parent group could be buried in notices.
This is especially true if you combine collector groups into larger collector 
groups; i.e. regional HR groups into a top-level company HR group.
If someone needs the notices, put them in that regular group.

Let us know how you decide to proceed.
HTH,
Joel
Joel Sender  *   jdsen...@earthlink.net

From: ARSList [mailto:arslist-boun...@arslist.org] On Behalf Of Lippincott, 
Levi (OMA-GIS)
Sent: Monday, June 4, 2018 9:56 AM
To: 'arslist@arslist.org'
Subject: Support Group Structure Recommendations

Hello ARSList!

I work for a company that has several companies it owns which in turn own many 
companies themselves which translates to several hundred companies around the 
globe.

Think of the company structure as:
Main Company
Sub Company 1
Sub-1 Company 1
Sub-1 Company 2
Sub-1 Company 3
Sub-1 Company 4
Sub-1 Company 5
Sub Company 2
Sub-2 Company 1
Sub-2 Company 2
Sub-2 Company 3

Our local IT support often handles support for multiple companies, typically 
under the same sub parent company though sometimes they can handle multiple sub 
parent companies at the 1 or several sites throughout a city. So for years we 
have operated under a model where our local support group policy has been 1 
group per city per company.

This has served us well up until more recently. Now we have several local IT 
support teams that are providing support for larger sub parent companies and 
they are now supporting multiple cities which has led them to be a member of 
50+ support groups. This is creating a performance issues when loading & 
refreshing their Incident Management Console.

Our other challenge is we have one helpdesk that relies heavily on the custom 
assignment rules to be able to send tickets to the correct location's local 
support when they need to escalate an incident to a field tech.

So we have been considering different methods to structure these groups in a 
way that we can minimize the number of groups they belong to, to increase 
performance, but we keep running into the challenge of those assignment rules 
becoming complex and hard to manage.

We just upgraded, a couple weeks ago, from 8.1.00 to 9.1.04 and I've just 
become aware of the Parent Groups and it seems that might be a good approach 
but I don't know how well it will work in practical application especially with 
the note I saw in the documentation: "Hierarchical group relationships are used 
for permissions management only, and are not recognized when sending 
notifications by group."

Does anyone have any recommended methods of handling this type of a structure? 
Does anyone have any use cases they've encountered throughout their careers 
that we might be able to apply to 

RE: Support Group Structure Recommendations

[Joel D Sender]

Levi,

Hierarchical groups allow 'parent' groups to include other groups.

All the 'Sub # - Company 2' groups could be collected into a 'parent' group,
across Tenant Companies.

For example, if each 'company' had a separate HR group, a master HR group
could include them all.

 

That notices only going to regular (non-collector) groups is actually a
feature; a member of a collector/parent group could be buried in notices.

This is especially true if you combine collector groups into larger
collector groups; i.e. regional HR groups into a top-level company HR group.

If someone needs the notices, put them in that regular group.

 

Let us know how you decide to proceed.

HTH,

Joel

Joel Sender  * jdsen...@earthlink.net  

 

From: ARSList [mailto:arslist-boun...@arslist.org] On Behalf Of Lippincott,
Levi (OMA-GIS)
Sent: Monday, June 4, 2018 9:56 AM
To: 'arslist@arslist.org'
Subject: Support Group Structure Recommendations

 

Hello ARSList!

 

I work for a company that has several companies it owns which in turn own
many companies themselves which translates to several hundred companies
around the globe.

 

Think of the company structure as:

Main Company

Sub Company 1

Sub-1 Company 1

Sub-1 Company 2

Sub-1 Company 3

Sub-1 Company 4

Sub-1 Company 5

Sub Company 2

Sub-2 Company 1

Sub-2 Company 2

Sub-2 Company 3

 

Our local IT support often handles support for multiple companies, typically
under the same sub parent company though sometimes they can handle multiple
sub parent companies at the 1 or several sites throughout a city. So for
years we have operated under a model where our local support group policy
has been 1 group per city per company.

 

This has served us well up until more recently. Now we have several local IT
support teams that are providing support for larger sub parent companies and
they are now supporting multiple cities which has led them to be a member of
50+ support groups. This is creating a performance issues when loading &
refreshing their Incident Management Console.

 

Our other challenge is we have one helpdesk that relies heavily on the
custom assignment rules to be able to send tickets to the correct location's
local support when they need to escalate an incident to a field tech.

 

So we have been considering different methods to structure these groups in a
way that we can minimize the number of groups they belong to, to increase
performance, but we keep running into the challenge of those assignment
rules becoming complex and hard to manage.

 

We just upgraded, a couple weeks ago, from 8.1.00 to 9.1.04 and I've just
become aware of the Parent Groups and it seems that might be a good approach
but I don't know how well it will work in practical application especially
with the note I saw in the documentation: "Hierarchical group relationships
are used for permissions management only, and are not recognized when
sending notifications by group."

 

Does anyone have any recommended methods of handling this type of a
structure? Does anyone have any use cases they've encountered throughout
their careers that we might be able to apply to our scenario?


Thanks!

Levi

This message contains information which may be confidential and privileged.
Unless you are the intended recipient (or authorized to receive this message
for the intended recipient), you may not use, copy, disseminate or disclose
to anyone the message or any information contained in the message.  If you
have received the message in error, please advise the sender by reply
e-mail, and delete the message.  Thank you very much.



---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
-- 
ARSList mailing list
ARSList@arslist.org
https://mailman.rrr.se/cgi/listinfo/arslist