Date: Wednesday, February 24, 2016
Q: CMDB/Asset Mgmt data -- is considered "Configuration Data" or "Transaction Data" ?
A: CMDB contains Configuration Items data and Asset has a life transactional data stored in AST:Attributes.
Q: What is the length of RLS field 112 OOB? There may be groups that have hundreds of people in a given group; is there any concern with running out of characters in 112?
A: The length of 112 field is 255 characters. With 9.1 release, we are storing the login ID of individuals directly associated to the ticket and the permission Group ID of the support groups associated to the ticket. The size or number of peoples within the support groups doesn't matter. We don't see any issue with field size as we can have at max 3 support groups supporting the ticket and at max. 3 individual associated to the ticket.
Q: Will the Contact (if filled in) be able to view the worklog if it is set to internal? Or is the restriction limited only to the Customer?
A: The restriction will be applicable to Contact person as well. If the Worklog View access is set to internal, then we are removing the Customer and Contact login IDs from the Work Log 112 field
Q: In ITSM, we have something called "Incident Master". This gives the user access to all incidents within the Company. How does this map to this new feature ? Do I need to have my Incident Master either belong to the Owner Group or all groups ?
A: Incident Master - application functional role and provide available functionality . Access to the record driven by RLS. To access record - Incident Master should be part of some group assigned to the ticket.
Q: How would managers get summary reports across support groups?
A: Managers should be part of parent group of support groups, or member of all required groups.
Q: So would only the parent group ID be listed on the field 112 then? or would it include the children as well?
A: 112 would contain the login IDs of individuals associated to the ticket and the permission group ID of the support groups associated to the ticket. The parent group would be stored in a different field and will be automatically populated by AR server. In our case, Parent Assignee Group  is the parent field of 112 and Parent Vendor Assignee Group  is the parent field for 60900.
Q: Will this change to 112 has any effect on the Access Restriction functionality where we provide company based restriction on the data to be visible to end users?
A: The answer is it depends on how company is related to the request. We have two different types of data:
1) Configuration data: There is no change and will continue to work as is.
2) Transactional Requests: In order to handle such cases, we have updated the parent groups of all the support groups with their respective companies. So in this case, if your access restriction company is related to assignment data, you will get access to the request. But if your company is just related as Customer Company which means you belong to Customer Company, then such users won't get access unless he is the customer himself.
Q: Will this hierarchical access still work in BOE Analytics reports?
A: BMC Analytics permission model is based on ‘Companies’ than Groups; no changes to Analytics permissions as part of these 9.1 enhancements.
Q: does the access for support group roll up apply to multiple companies... such as specific support groups from one company, having access to records / data for other companies?
A: The answer is yes. But you will have to configure the hierarchy in such a manner.
For example, you have support groups from Company A. You can define the parent group of all these support groups as Company B. With this in place, users belonging to Company B will have access to tickets assigned to support groups from company
Q: So if this IT Data Access parent group example has 170 support groups part of it; will 170 IDs exist on this 112 field or just the ID of IT Data Access? I would hope just parent ID, or else you will run into char max pretty quick.
A: Only the parent group is referenced. But the Parent Group Id is put into the Assignee Group Parent field, not the Assignee Group (112) field.
In your example - all records related to 170 support groups will have the IT Data access Group ID value in a parent field.
Q: Is the Hierarchical Group Configuration form part of ITSM, or is it a base ARS form?
A: Hierarchical Group Configuration form is a display only form and is part of ITSM. In the background, it updates the Parent Group field of Group form which is a AR Server form
Q: Is the parent group setup part of the Data Management spreadsheets?
A: In 9.1 the Hierarchical Group fields are not part of the UDM spreadsheets.
In 9.1 we provide configuration UI to set up group hierarchy for Company and Support Groups.
Feature for UDM will be available in future release of Remedy ITSM.
Q: making sure I understand... a support group could be set up with a Parent Group that is a Support Group AND a Parent Group that is a Company. Right? (not one or the other. could be BOTH)
A: Can be any groups stored on a Group form.
Technically both the combination would work. You need to configure it correctly based on your functional needs
Q: What is the performance impact of this operation in a large production environment?
A: Hierarchical Groups can actually improve performance in large complex environments with lots of groups. Prior to 9.1, the only solution was to add the user to all the support groups and that list was really large. With 9.1, you can organize your support groups using hierarchy and associate the user to needed parent groups.
Q: Does update all tickets or only open ones?
A: The parent group hierarchy changes updates all the requests including closed requests. But it doesn't update the last modified By and Last modified Date fields.
Coming to the performance aspect, it will not impact the performance. The parent group updates happen in the background and there are separate threads dedicated to it.
Q: Can we control whether these hierarchical groups appear in the incident assignment list or not ? There are cases where these are just available for viewing/reporting, but not for assignment.
A: Yes. the data in the assignment menus can now be controlled and it is configurable. With 9.1, we have introduced a new configuration form, where you can define the list of support groups available for assignment for a company.
Q: why system gave a message "You do not have permission to edit the ticket"? when Ashok searched for the old ticket?
A:User role not allow write access to the ticket. This hasn't changed.
Q: How does the Unrestricted flag play into this .. for users who have Unrestricted Access checked on the People record?
A: Unrestricted access - part of permission on field 1 as well as RLS related fields. Still works in a new structure
Q: When the hierarchy is updated does it modify all tickets or just open tickets? What is the impact of this change in a large production environment? What about historical data and reporting as it relates to this hierarchy?
A: Updates all records as a server feature. Updates happened on a backend, should be no problem. Just takes some time.
Q: Does a new company generates a new group (as it was in previous versions)? Or isn't it needed and company doesn't generate a new record in Group form?
A: Yes. For a new company record will be created on a group form
Q: so we use customer companies...how does this impact us being able to have customers have access only to tickets for that company but then restrict to tickets for specific support groups assigned tickets under that customer company
A:With 9.1, the transactional requests are restricted to individuals and support groups associated to the ticket. But we also have a new feature called hierarchical group and during upgrade, we are updating the Parent group of all the support groups with their respective companies.
So if I take the case of Incident management, and assume that owner group belongs to Customer company, there is no impact. All the members belonging owner company will get access to the request.
Q: We plan to create a new Fresh Install and then migrate transactional and foundational data using BMC's partner Alderstone CMT tool...how would this migration be affected by this hierarchy change?
A: Your records will have data based on Company. Only newly created records will go with a new structure.
You should ask Alderstone to confirm support.
Q: I am guessing that for these Assignment menus, this works in SmartIT as well as in the Mid-Tier
A:Yes, this new feature would be available in 9.1 midtier UI and Smart IT 1.3.01 release.
Q: So if everyone has Unrestricted Access ... that will override any configured access permissions correct ?
A: Yes. Correct. As unrestricted access part of permission on a field 1. In this case only application role will restrict access.
Q: What all Company access restrictions has the "app User " has??
A: App user permission give you access to applications and forms. Record access driven by RLS.
Q: Do we need to add support group every time when we create a new support group, or this is required only if we need to add different support group as assignment group for different Company's Incident
A: When you create a support group, it will add the assignment mapping to its company. You'll need remove it from the assignment mapping if you don't want to use it.
Q: Can the available assignment groups be limited by Support Group or only by Company?
A:Whenever you create a new support group, it will automatically add the assignment mapping to its company. You'll need to remove it from the assignment mapping if you don't want to use it
Q: Can't you also control that by making all of the member Assignment Availability = No?
A: Member Assignment Availability function is applicable to individuals. When we set this No, it means that member is not available for individual assignment. With support group assignment configuration, we are providing a functionality where you can define the list of support groups available for assignment for a particular company.
Q: Is it possible to configure group assignment and visibility for specific ticket types? Example: Define that a specific group will only be visible for the assignment of change requests, but not for incidents.
A: It is a global setting currently. We haven't broken it down to ticket types.
Q: In what version of SmartIT will we see these changes in 9.1? Will it work for all versions of SmartIT or only a particular version going forward?
A: I believe it is SmartIT 1.3.1 and higher
Q: What about administrator..regarding this support group restriction... will the administrators be able to see all the support groups?
A: Yes. Administrator has no data restriction
Q: now once you removed the group IT Access group , are the group able to review their own tickets ?
A:IT Data Access group was the parent group. If you remove the hierarchy members belonging to parent group will not have access to the request. But the support groups supporting the request would continue to have access to the request.
Q: Does new workflow in version 9.1 resolves problematical status, when we used too many companies (about 1M), this status has very negative impact to performance. Problem is in too many groups in the group form
A: HG feature can help. By optimization of groups.
Q: Is any difference between Incident User and Incident Master user in Service Desk 9.1 regarding access to tickets?
A: Application permission still the same.
Q: when you have an assignee group on the task of a change record, does that task assignee group have view and/or write access to the change? assume that the task assignee group is not the change coordinator of change manager group.
A: Opposite way enforced. Change can see Task, Task assignee can see change if assignee part of change permission as well
Q: After 9.1 if I create a new hierarchical group will it update closed tickets?
Q: Which one is BMC approach to keep 8.1 approach to ticket access? Create a "hidden" supergroup with all Support staff?
A: Existing data prior to 9.1, the field permissions will remain as is.
Also, as part of the upgrade all support groups will have their Parent Group be set to the Company the support group belongs to. This provides backwards compatibility.
Q: Regarding the BOE question, BOE gives full access to all of the details of a record. So my question is whether a user will be able to run reports on all data, or if their data will be restricted to those records they would have access to in Remedy.
A: All data
Q: When adding a new parent group to the support groups, you mentioned that the system needs to update the records. Is there a performance issue with this? Does it update the last modified by and last modified date? And will it update closed records?
A: Changing the hierarchy would update all the records. This includes both open and closed requests. From the Performance aspect, it would consume additional CPU usage, but there would be no impact to the user so far as data access is concerned. User can continue with routine tasks. AR performs this task in the background and have dedicated threads to it.
It doesn't update the last Modified by and last modified time. Only the parent field values gets updated.
Q: Does a person with a hierarchical group also need functional role assigned?
A: Function roles and permissions are for different purpose. They determine whether you can update the request or advance the request throughout the life cycle.
The hierarchical group feature will enable you to roll up the data access which means the row level access. It will determine whether AR wound return you the requested row or not.
Q: Will approvers be provided access anyway to their waiting approval tickets?
A: Approvers would be able to approve the request from approval central. If they want to approve the request from application UI, they would need row level access which means has to be part of either assigned groups or parent groups.
Q: Regarding my previous question "Which one is BMC approach to keep 8.1 approach to ticket access? Create a "hidden" supergroup with all Support staff", I meant how to achieve in a clean 9.1 the same ticket access approach that 8.1 had. Could you clarify it?
A: To get a similar behavior in 9.1 to the behavior in 8.1, just make the Company the Parent of the Support Groups
Q: No,, There was user named "app user " used to demonstrate Support Group visibility in other company. So I wanted to know that user's company access
A: “App user” was having unrestricted access as that user was doing the configuration for multiple companies.
Q: are the updates in the backend for adding a new parent group done in the backend similar to data wizard in v8? if so, data wizard can cause an impact to performance due to the number of records and BMC recommends not doing during peak hours.
A: The answer is No, this is an AR feature and AR populates this field. There is no workflow involved.
Q: will this affect access permissions within the asset management module? Will parent support groups have change access to asset records?
A: Will effect only read permissions.
Q: We use incident viewer for end customers to review their own incident records. They are not part of any support groups, just the incident viewer. Will they still be able to review their incidents?
A: No changes on this case. Viewer will give you access to incident application. With 9.1, customer login ID is part of 112. So he will be able to view his own incidents.
Q: The example we saw was on Incident form for populating 112, what group ids will be added in the 112 for other ITSM module like Change, release and problem as they have multiple assignment(coordinator, implementer, manager..)
A: The concept is simple: Users associated to the ticket and support groups associated to the ticket are part of 112.
For more details on each application, refer https://docs.bmc.com/docs/display/public/itsm91/Row-level+security
Q: In regards to the incident viewer questions; this would be the customer listed on the incident ticket; not the submitter.
A: With 9.1, Customer Login ID is part of 112 value. So the customer would get access to the request. He simply needs Incident viewer permission.
Q: This new feature in ITSM 9.1 is the Support Group Assignment Configuration. We have a few hundred support groups configured and we have a few hundred external customers that we support. We would like to turn this feature off. It is not feasible for us to map each of our support groups to each of our customer's companies and do this each time we add a new support group.
I would like all of our support groups available for Incident assignment for all tickets that are entered.
A: This as data security issue where wrong assignment can lead to data visibility across tenants vs. being a new feature. There isn't a switch/configuration to turn off this feature.
For your use case, you can simply add all your companies to each of the supporting companies. In case you are using auto assignment, this would be done automatically for you.