User is not able to Add Affected CIs to an Outage Record<!-- div.margin { padding: 10px 40px 40px 30px; } table.tocTable { border: 1px solid; border-color: #e0e0e0; background-color: #fff; } .title { color: #d1232b; font-weight: normal; font-size: 28px; } h1 { color: #d1232b; font-weight: normal; font-size: 21px; margin-bottom: 5px; border-bottom-width: 2px; border-bottom-style: solid; border-bottom-color: #cccccc; } h2 { color: #646464; font-weight: bold; font-size: 18px; } h3 { color: #000000; font-weight: bold; font-size: 16px; } h4 { color: #666666; font-weight: bold; font-size: 15px; } h5 { color: #000000; font-weight: bold; font-size: 13px; } h6 { color: #000000; font-weight: bold; font-size:14px; } ul, ol { margin-left: 0; list-style-position: outside; } --> Symptoms User is unable to add Affected CI to an outage record Release All Cause By default, the Affected CIs table has no ACLs present so if high security plugin is enabled (which on majority of instances this is active) only Admin users can successfully add CIs to outage record. The reason being is that in the absence of ACL the default access for any CRUD operation is to deny. When an outage record is associated to an 'Affected CI' the system is actually creating a m2m relationship which results in a write to the table for Affected CI (cmdb_outage_ci_mtom). As there are no ACLs present any operation against this table would be denied with exception of Admin users. Resolution The solution is to create two ACLs Table read ACL on cmdb_outage_ci_mtomTable create ACL cmdb_outage_ci_mtom Admins/Application Admins can configure ACLs as needed so that not all fields are read/writeable.