Issues caused by the plugins incompatibility

A plugin conflict is something that occurs when two plugins are incompatible with one another.

For example, when you're having issues with one plugin functioning properly, often the problem is caused by a conflict with another plugin.

Note: Detecting the conflict is very important step to take because the problem can be resolved easily.

The following is known issue you may get when using Shield with other certain plugins.

Shield conflicts with Divi Page Builder Plugin

If you have Shield's Lockdown module enabled and you've used the option "Mask WordPress Version", it can happen that this option conflicts with Divi's Color Picker feature.

This sort of compatibility with that version masking option is to be expected. It can cause quite a bit of interference with plugins that rely on that setting to be accurate.

Important update: "Mask WordPress Version" option is removed in Shield v9.0. So, generally, there is no conflict there.

Elementor Pro wont edit pages unless its in safe mode

If Elementor Pro doesn't edit pages unless its in safe mode, the problem is likely caused by Elementor using iframes and your restrictions break it.

In this case, you will need to review Shield's HTTP Headers settings.

You may go to the Advanced Security Headers => Block iFrames, and then change settings from 'Block All iFrames' to 'On: Allow iFrames On The Same Domain':

Avada Live builder won't load or edit pages

Just like for Elementor, you'll need to change Block iFrames setting in Shield - set to 'On: Allow iFrames On The Same Domain'. 

Conflict with WP Bakery plugin

For example, the theme Xtore uses WP Bakery as builder. It has the functionality called 'Static Blocks' and it uses role management to decide which user can use these blocks.
When you have Security Admin - Admin Users option enabled in Shield, the static blocks edition with WP Bakery does not work for other admins. It does work for editors and all other allowed users.
In this case, you'll need to disable Admin Users option:

Our code will simply restrict certain capabilities, namely 'edit_users' and 'create_users' and only in the specific case of HTTP POST requests pertaining to the modification of a user's administrator role.
We're not sure how the WP Bakery plugin would be triggering it, but it's quite possible they are... but then they'd have to then also be looking up the capabilities mentioned above.
The other possibility, and frankly the most likely, is that they're using the function "get_editable_roles()" to determine whether the current user is an admin, or ratherwhat their role is. This is quite unorthodox but it's our first suspicion here.
If get_editable_roles() contains "administrator", then it suggests that the user is admin. The converse also being true. But in the case of this Security Admin option, we remove "administrator" from the list of editable roles. When you contact the WP Bakery plugin developers, you could suggest they don't use this as a reliable indicator of role level... far better use "user_can( 'manage_options' )".