Few GRC/IRM Product Defects with their workaround/solution

[KG2]

In the GRC Rome/San Diego Version, we have identified below Product defects where we got the PRB raised, suggested workarounds/permanent fixes for those PRBs.

This info might help other users who are facing same issue without spending a lot of time on investigation. We have mentioned the solution and PRB number for reference with details on the issue.

Sr.No	Short Description	Details	Solution/Workaround	Problem
1	Some GRC entities created without RAM even though the RAM for that class exist.	Analysis: 1.        All the configurations and BRs are OOB.  There are 2 BRs which are used to set class on the entity record and RAM on the entity. 2.        The BR “Assign class to profile” which sets the Class on the entity record (runs on Before insert/update and on order 100). 3.        The other BR “Add roll up result on RAM/class change” sets the Primary RAM on the entity record. The BR runs on order 100 and on Before insert/update. 4.        Ideally “Add roll up result on RAM/class change” should run after the assign class to profile BR, as it has condition on change of Class OR Risk Assessment Methodology. 5.         Since both BR runs on same order, the behavior of setting RAM on entity is erratic. Please note the same behavior is found in personal developer instance as well.	Solution:  We modified the order of BR “Add roll up result on RAM/class change” to 1000 and it worked as expected.	Problem number: PRB1520465
2	GRC Policy Exception Request Extension is setting substate as 10.0 instead of Under Review(10)	Intermittent issue on Policy Exception was reported where substate value on Policy Exception records was displaying as 10.0,11.0 instead of their label values like Under Review/Approved. Please find below my observations which might help in investigation : The script include sn_compliance.ComplianceAjax has a method addExtension() that sets the substate to 10. Please note the value for this is 10 and not '10'. The field substate is a string field. I changed it to exception.substate = '10'; and it reflected correctly on the form but the later steps (approve/reject) appear as 11 or 12 in substate(since those scripts too set it as integer). This is a string field and is setting it without quotes which might be causing the problem ? But please note there is no issue in PDI instance and the value of substate in there is also set without quotes only and it works fine there.	Workaround: We created a before update BR which will run whenever substate changes and update the substate(if substate is set as integer) from integer to string value. (since in all the OOB scripts, they are referring substate value as integer, it is better to create one BR instead of updating multiple OOB scripts)	Problem number: PRB1520960
3	Configuration item field on sn_grc_issue form does not re-populate to correct value on update of Control/Risk	The 'Configuration Item' field on Issue didn't get updated based on control/risk selection(It only displays/saves correct CI while new record is created). We found out the OOB BR "Auto populate cmdb_ci field" which updates CI based on control/risk runs only on INSERT and not UPDATE	Solution: OOB Business Rule "Auto populate cmdb_ci field" which updates CI based on control/risk runs only on INSERT and not UPDATE. Make it run on both INSERT AND UPDATE	Problem number: PRB1576692
4	Engagement Tier should set once Tiering Assessment for engagement is closed by Vendor Assessor.	1. OOB - Vendor Tier is updated on Vendor records once the tiering assessment is closed even by vendor assessor(sn_vdr_risk_asmt.vendor_assessor). 2. Similarly ,  once an engagement tiering assessment is closed, the engagement tier is set on the Engagement record but only if the tiering assessment was updated by vendor risk managers and not vendor assessor. 3. OOB BR - "Copy vendor tiering to engagement" has Role Conditions as sn_vdr_risk_asmt.vendor_risk_manager which runs only if logged in user has vendor_risk_manager role.	Solution: OOB BR - "Copy vendor tiering to engagement" has Role Conditions as sn_vdr_risk_asmt.vendor_risk_manager , remove the role condition. This has been fixed OOB in Vendor Risk Management V 15.0.7	Problem number: PRB1569162