Methodology
- Start with a failure state
- Investigate and gather evidence
- Review possible causes
- Test to find the root cause
- Provide a Solution
Scenario:
Failure State
Affected user had 1 application that was unavailable to her anymore.
App was working just fine 1 day before.
User cannot see the app in SF anymore.
Other users can see the app.
Investigate and gather evidence
No user errors visible in SF
Other apps from same DG work with no issues
Health test for DG has been ran, no issues except 1 has been found which was not related to app.
Review possible causes
- SF enumeration failure (NO – other apps were shown ok)
- DG not workin (NO – other apps are launching)
- Connection brokering failure (NO – there are no brokering issues)
- Resource availability constraints (NO – no constraint messages found)
- Delivery Group/apps misconfig (YES (remaining possible cause for some reason?) checks must be performed.
Test to find the root cause
Studio has auditing and compliance tool known as „Configuration Logging”
- Manual changes are captured in the log
- Automatic actions are not
Due to permission restrictions, matter has to be escalated to an engineer that has more permissions.
Upon review from escalation engineer, he used logging to check if there were any changes performed for the affected application and in the timeframe between which user advised app worked and did not work.
Issue was that previously configured security has been removed while a user has been added instead of another security group