29 01 2014
Supporting Office 365 Customisations
So it seems that people are beginning to bear the ugly side of hosting solutions on a hosted platform (that you don’t own) – and that’s having the platform updated without being informed!
This is all well and good, because the features that Microsoft control are continually being tweaked, and if they don’t work as expected the onus is on them to fix it.
But when us Partners come along and tweak things further, sometimes things can break. A good example of this recently was documented on Marc Anderson’s blog: http://sympmarc.com/2014/01/23/office-365-update-changes-display-name-on-required-fields/
So, when we’re managing support to our customers on Office 365, how can we mitigate the fallout of this?
Well, thanks to Cory Peters, there’s a way we can get the version number a specific tenant is running on: http://corypeters.net/2013/07/getting-the-product-version-for-sharepoint-online/ (He forgot to mention that you must visit the magic URL from the top of your web application).
With that key piece of information that you get from there –
Record this version number in your go-live handover/completion documentation.
Certified working with buildversion:
Now when your client’s customisations suddenly start breaking (after your warranty period) you can make reference to this version number and see if it has changed for your client’s tenant.
How you handle this is up to you. For example, in the cost that you compile for your support contract, you could allow X number of days for investigation due to ‘undocumented updates by Microsoft’ (basically, broken functionality caused by changes in the buildversion).
Another thing to do is to inform your customer that some functionality that you build may fail due to Microsoft updates – as long as you somehow clarify what part of your solution could break in future updates that you would need to rebuild/rework (e.g. “All lists will work fine, but this form where we have validation might need to be tweaked if it stops working”).
You don’t really want to end up stiffing your customers (“hey, MSFT broke it, but I’ll fix it for your at our full day rate, like it or lump it!”) – well you could but you better be good at customer service, otherwise you put yourself AND Microsoft in a bad light.
These are early days so it will be interesting to see how other Partners will be handling this rather “Agile” approach to platform stability!