Closed radcox closed 2 years ago
@radcox, this is due to sys_class_name, an alias for -Table, not always being the same as the table name; in the case of alm_asset this is always true. Add -table alm_asset
to Update-ServiceNowRecord
and try again.
Instead of get-servicenowrecord -table alm_asset -First 5000 | ? { $_.serial_number -match 'XXXXXXX' }
, you are better served by adding a filter to the query. get-servicenowrecord -table alm_asset -First 5000 -Filter @('serial_number', '-like', 'xxxxxx')
. This will only bring back the data you are looking for, always a good thing, which could definitely be less than 5k records. Also, as is, there's a chance what you are looking for isn't in those first 5000 records.
Thank you for this information, it was a 2 fold issue, yes, adding the -table parameter for alm_asset (due to sys_class_name) allowed the value to be written but the service account also did not have the appropriate write permissions despite what I was informed (since I don't have access to manage SN permissions.) I agree that using the filtering is more appropriate and much more efficient. Thanks again, Huge help.
Environment
Steps to reproduce
ex1: $var = get-servicenowrecord -table almasset -First 5000 | ? { $.serial_number -match 'XXXXXXX' } $Var | update-servicenowrecord -values @{warranty_expiration = '07/14/2022'}
Expected behavior
Update Warranty field with Date String
Actual behavior
Nothing happens when executing the PS Commandlets unlike with other SN Data Types like: INC, REQS, RITMs etc... The reasoning this is needed is to use another process to obtain the warranty information and to ingest it for the specific SN Asset under the appropriate warranty information property. I am positive the account has full access to be able to read/write to this table and I am able to update other SN item types when specifying the ID is possible unlike with Asset items.
Screenshots