SaaS Configuration
When building B2B SaaS platforms, software becomes riddled with hundreds of configuration settings. These settings control flows, adjust limits, modify logic, and other aspects of the platform. Some of these configuration settings start as simple configuration options used by developers to control development and testing environments. Many others “organically” spring to life as SaaS customers and prospects provide feedback on what they like and what they would like to see changed for their particular implementation. In some particularly complex scenarios, a single “client” may have multiple facilities which each require independent configuration.
Settings can be designed in layers. System settings affect the core platform and should not be manipulated by anyone except the publisher of the software. For example, you wouldn’t want clients changing your database connection string. Application settings might be used to turn sections on or off. These can be used to keep incomplete features from being released into production before they are ready, but still allow teams to test in non-production environments.
Customer settings are highest on the stack and can be far more nuanced. As a publisher, your direct clients may want to configure settings. For example, if your system processes electronic payments, you may have limits for each client to control the maximum transaction amount. However, one client might have several locations, each which has a different limit. What if you have a client that does not set a value? What value should be used? As the publisher, you might configure a rational limit that could be used. Likewise, if a client satellite office does not set a value, the main office value should be used.
As you can see, a hierarchy of values exists. Current frameworks, such as .NET or Java, have components to manage settings, but they are, at best, system-level or application-level settings. SaaS publishers need something more sophisticated to manage settings at all levels.