In our early efforts to automate D365 with Selenium, we noticed that the tooltips frequently interfered with our click attempts. That might be happening to you. One thing I've tried is using MouseActions to move the mouse away from the button before clicking -- it should avoid triggering the tooltip.
One particular issue we've run into is clicking items in tables. Selenium only lets you click on the table cell, but D365 only accepts clicks on the linked text in the cell. If the cell column's width is 2x the width of the text or greater, a click on the cell will fail to click the text (by default clicks on elements are on the centroid of the element rectangle). The solution to this was to use sendKeys to use keyboard navigation and use Keys.ENTER on the cell, which triggers the link.
One thing to note about D365 is that a lot of page actions will cause a very momentary modal screen to occur. The user rarely notices, but Selenium often will. A lot of our interactions are prefaced with a wait for any such modal to disappear. (Can't remember the class name off the top of my head.)
Another thing to know is that when you transition between pages, you're not really changing pages, but simply getting the new page on top of the previous ones. If there's any buttons on previous screens that match buttons on the current screen, you will likely be hitting the previous ones instead of the active one. The sure-fire solution there is to preface locators with "form.active-form" or "//form[contains(@class,'active-form')]" (I really recommend the css version) which will encompass the current "visible" page.
And then of course there's D365's non-reliable element IDs that put a "workspace id" in every element ID that changes from time to time...
It's been a lot of pain (and shade-throwing) trying to automate D365 UI. We are stuck doing it because we also need to integrate with many other third party applications. Whenever possible we look for alternatives such as using APIs or DB calls instead of the web UI.