Unable to set Company field on many Configuration Items
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
06-21-2023 12:54 AM
Hi,
We've encountered an issue where Staff at "COMPANY X" can only see CIs registered against "COMPANY X".
This itself isn't an issue, however there are a number of CI Classes, such as Application, Application Service where the Company field isn't editable.
Can anyone suggest why this is the case or identify a way to rectify it?
Configuration Items with Assets, do appear to be selectable, e.g. Servers, etc. but not the Application/Application Services. Nor are the Business Applications.
We need these setting at a high level as the end user wouldn't have a clue where the issue is, nor would many of our Service Desk staff.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
06-21-2023 06:23 AM
HI @Tom104 ,
I trust you are doing great.
Verify User Roles and Permissions: Check the user roles assigned to staff members at "COMPANY X" and ensure they have the necessary permissions to view and edit CIs. Ensure that the roles have the required access to the CI Classes in question.
Check CI Class Configuration: Review the configuration of the CI Classes such as Application and Application Service. Verify if the Company field is marked as read-only or if any access controls are preventing edits. You can find the CI Class configuration in the ServiceNow Studio or by navigating to the CI Class form.
Examine Access Controls: Look into the access controls defined for the CI Classes. Access Control Rules (ACRs) determine which roles can access and modify specific fields. Ensure that the appropriate roles have the necessary access to edit the Company field.
Review Business Rules and Scripts: Investigate any business rules or scripts that might be enforcing the read-only behavior on the Company field. Check for any conditions or scripts that prevent editing of the field for certain CI Classes. Look for UI Policies, Data Policies, or other custom scripts that could affect the field behavior.
Test and Apply Changes: Once you identify the potential cause, test any changes in a development or testing environment before applying them to the production instance. Make necessary modifications to the CI Class configuration, access controls, or scripts as per the requirements.
Here's an example of a script that could help investigate the CI Class configuration:
// Run this script in the background script or script editor to display CI Class details
// Specify the sys_id of the CI Class you want to inspect
var ciClassSysId = "<sys_id_of_ci_class>";
// Get the CI Class record
var ciClassGR = new GlideRecord('cmdb_ci_class');
if (ciClassGR.get(ciClassSysId)) {
// Print relevant details of the CI Class
gs.info("CI Class Name: " + ciClassGR.name);
gs.info("Is Company Field Editable: " + ciClassGR.u_company_field_editable);
// Add more fields to check as needed
} else {
gs.error("CI Class not found with sys_id: " + ciClassSysId);
}
Was this answer helpful?
Please consider marking it correct or helpful.
Your feedback helps us improve!
Thank you!
Regards,
Amit Gujrathi