Atlas Bug fixing process

This article gives more insight into how we handle bug fixes for our Atlas clients.

When clients identify a (possible) bug they can raise a support ticket on Zendesk. During an initial investigation, we'll define whether the issue really is a bug and when identified, the specific type of bug will be defined.

• Atlas bugs
  These are bugs specific to Atlas.
• SharePoint bugs (non-Atlas)
  Any type of bug in generic SharePoint and not specifically related to Atlas. This means that the issue can be reproduced in a blank SharePoint environment.
• Third-party bugs
  These are bugs related to third-party solutions used in the SharePoint or Atlas environment.

Process for Atlas bugs

For bugs identified on Atlas and reported to the Product Owner, the following process and time considerations will be followed:

1. Issues are promoted to bugs in the Atlas product backlog.
2. The bug is picked up in the following sprint (not the current one).
   Note: we have bi-weekly sprints so bugs are picked up within 10 working days.
3. When the new sprint starts the bug will be picked up as a commitment in the product backlog. 
4. We'll provide the fix to the client via the next Atlas release where we'll update the environment to the new release version, which will at the same time resolve the bug. Your CSM will keep you fully up to date on the progress.
   If the issue is to have a critical impact on the client, where the client can't wait until the normal release date, we might look into deploying a hotfix. In very rare instances, this will be possible after coordination with your CSM and under the condition resourcing is available. 

Emergency process:

In case of a major/emergency bug we might pick up the bug ASAP and provide a fix to all clients as fast as possible, which will have an impact on the Atlas release cycle. 

Process for SharePoint bugs

If the bug is something in our SharePoint code this will be resolved ASAP depending on resourcing and complexity. The support team will coordinate all necessary actions and keep the client informed via the support ticket during the whole resolution process.
If the bug is a generic SharePoint bug (original Microsoft code) then we'll raise a Microsoft ticket and coordinate with Microsoft who'll then action on the issue as per their internal process.

Process for Third-Party bugs

In case of third-party bugs we'll confirm the webpart, or our configuration settings, is correctly working and once our side is confirmed and the problem is still not solved, the issue might have to be escalated to the third-party.
Depending on the situation, the agreement with the client and/or the third-party we can assist in coordinating but the resolution itself is out of our control and responsibility. The third-party will have to take the necessary corrective actions.

Client notification

We'll keep clients informed via our Atlas Service Health page and via a dedicated article on the specific outage or service disruption.