SEVERE *** ERROR *** Unknown credential type downloaded; MID server may not have access to credentials tableIssue <!-- /*NS Branding Styles*/ --> .ns-kb-css-body-editor-container { p { font-size: 12pt; font-family: Lato; color: #000000; } span { font-size: 12pt; font-family: Lato; color: #000000; } h2 { font-size: 24pt; font-family: Lato; color: black; } h3 { font-size: 18pt; font-family: Lato; color: black; } h4 { font-size: 14pt; font-family: Lato; color: black; } a { font-size: 12pt; font-family: Lato; color: #00718F; } a:hover { font-size: 12pt; color: #024F69; } a:target { font-size: 12pt; color: #032D42; } a:visited { font-size: 12pt; color: #00718f; } ul { font-size: 12pt; font-family: Lato; } li { font-size: 12pt; font-family: Lato; } img { display: ; max-width: ; width: ; height: ; } } MID server giving below errors during credential reload. This example is a Discovery Shazzam probe, but it will be seen from anything using Credentials from the instance, such as IntegrationHub IPaasActionProbe, Orchestration, and others. 2020-01-28 07:11:24 (351) Worker-Interactive:Shazzam-abd9117e1be6c8909f5bfe60cd4bcb88 SEVERE *** ERROR *** Unknown credential type downloaded; MID server may not have access to credentials table2020-01-28 07:11:24 (351) Worker-Interactive:Shazzam-abd9117e1be6c8909f5bfe60cd4bcb88 Credentials from instance loaded "MID server may not have access to credentials table" isn't true. It does, or it couldn't know the credential from the instance is wrong. Release<!-- /*NS Branding Styles*/ --> .ns-kb-css-body-editor-container { p { font-size: 12pt; font-family: Lato; color: #000000; } span { font-size: 12pt; font-family: Lato; color: #000000; } h2 { font-size: 24pt; font-family: Lato; color: black; } h3 { font-size: 18pt; font-family: Lato; color: black; } h4 { font-size: 14pt; font-family: Lato; color: black; } a { font-size: 12pt; font-family: Lato; color: #00718F; } a:hover { font-size: 12pt; color: #024F69; } a:target { font-size: 12pt; color: #032D42; } a:visited { font-size: 12pt; color: #00718f; } ul { font-size: 12pt; font-family: Lato; } li { font-size: 12pt; font-family: Lato; } img { display: ; max-width: ; width: ; height: ; } } Any Cause<!-- /*NS Branding Styles*/ --> .ns-kb-css-body-editor-container { p { font-size: 12pt; font-family: Lato; color: #000000; } span { font-size: 12pt; font-family: Lato; color: #000000; } h2 { font-size: 24pt; font-family: Lato; color: black; } h3 { font-size: 18pt; font-family: Lato; color: black; } h4 { font-size: 14pt; font-family: Lato; color: black; } a { font-size: 12pt; font-family: Lato; color: #00718F; } a:hover { font-size: 12pt; color: #024F69; } a:target { font-size: 12pt; color: #032D42; } a:visited { font-size: 12pt; color: #00718f; } ul { font-size: 12pt; font-family: Lato; } li { font-size: 12pt; font-family: Lato; } img { display: ; max-width: ; width: ; height: ; } } 'Type' field for a record on the discovery_credentials table is not present. For Example: "Twilio Direct Auto Generated" credential should be set to "Basic Auth" but it might be empty. It is not possible to delete this record from the UI action of both form and list view.That specific example was fixed in Quebec release by adding a dictionary override to set the default value (PRB1442205), but other examples might be seen. Resolution<!-- /*NS Branding Styles*/ --> .ns-kb-css-body-editor-container { p { font-size: 12pt; font-family: Lato; color: #000000; } span { font-size: 12pt; font-family: Lato; color: #000000; } h2 { font-size: 24pt; font-family: Lato; color: black; } h3 { font-size: 18pt; font-family: Lato; color: black; } h4 { font-size: 14pt; font-family: Lato; color: black; } a { font-size: 12pt; font-family: Lato; color: #00718F; } a:hover { font-size: 12pt; color: #024F69; } a:target { font-size: 12pt; color: #032D42; } a:visited { font-size: 12pt; color: #00718f; } ul { font-size: 12pt; font-family: Lato; } li { font-size: 12pt; font-family: Lato; } img { display: ; max-width: ; width: ; height: ; } } This record generally does not cause an issue with discovery of other devices as such., but the warning in MID Server agent logs can cause confusion and delay But if you encounter a scenario where this record is suspected to be the cause of a failed discovery or credential not being picked up by the MID server and would like this to be deleted, then you may use 'Table Cleanup' under 'System Maintenance' to remove this record. Steps: 1. Create a new record under Table Cleanup module for table 'discovery_credentials' 2. Give the filter conditions as 'sys_id' IS 'fee0097e1be6c8909f5bfe60cd4bdc11' (where 'fee0097e1be6c8909f5bfe60cd4bdc11' is the sys_id for the credential record with NULL type value) 3. Age in Seconds is '1' and Save the record. 4. Go to sys_trigger table and open 'Table Cleaner' record and hit 'Execute Now' Alternatively, you can also use a background script to remove the record or add a type value to this record.