← Misc

Use Cases to Configurations Guide

Summary

The purpose of this document is to provide a common language for Product and Engineering to use when discussing configuration options. There is no mandate to use this document, it’s simply provided to help our groups communicate more clearly. Comments and suggestions are welcome.

Product and Engineers work collaboratively to develop software used by our customers. Nearly all products/features that are developed have some sort of Configuration available to make the experience differ depending on the FI/Organization/User. The term Configuration is generic, but in this context can refer to anything from a one-time setup at FI onboarding, to user-level controls, and A/B testing.

Product owns the list of use cases. Engineering owns the list of available configuration methods with their associated pros and cons. Engineers will interpret the User Scenarios from Product and set the appropriate Solution(s). There is a mapping spreadsheet at the bottom for this User Scenarios → Solutions mapping.

Glossary

  • FI: Financial Institution. A Bank or a Credit Union.
    • Note: this refers specifically to a single brand (this distinction is only relevant if the FI is multi-branded; for example a retail brand and a wealth management brand)
  • JH Support/Implementation: these teams have access to live FIs in Production. They are able to edit configurations in that environment as part of their job duties.
  • JH Employee
    • JH Support/Implementation are always a part of this definition. It also includes other employees such as Developers, Product, Analysts, Design, etc..
  • FI Admin: an employee of a FI
  • Enterprise User: this is a more generic term to refer to either a JH Employee or a FI Admin.
  • End User (aka Consumer): a customer of a FI.
    • Note: this can be any type of user. Either retail or business.
  • Organization: a group that can be classified as business or retail, has its own permissions, and holds a group of users from 1 to many.
  • Consumer Admin: an End User who has permission to manage the Organization and organization-users they’re associated with.
  • Baseline: the experience is available to all users with no way to disable the functionality.
    • TODO(Carrie Acosta): Would like clarification on this as we often roll work to either banks or CUs first and need a way to disable experiences for the other until functionality is ready. Also, product has been specifically instructed to make all new functionality enabled/disabled.
  • Slow Rollout: a change to the configuration that is applied selectively (can be controlled at any level). But it is meant to be a temporary transition with the end goal of making the behavior available to all users of a particular Feature/Product.
    • For example a feature such as “download my transactions as a PDF”. We may choose to roll that out slowly to a small set of test users to validate features. But, once it has been validated, it becomes baseline.
  • JH Platform: the UI that Enterprise Users work in.
    • (Banno People)
  • Banno Online/Mobile: the UI that End Users work in.

Solutions (Engineering):

  • Solution 1: Abilities (Institution Level plus User Overrides)
    • Boolean On/off (easy)
    • Strings (extra work)
    • Enumerations (extra work)
    • Bespoke (extra work)
  • Solution 2: Abilities Institution Only
    • see above
  • Solution 3: Launchdarkly
    • can handle any Json type (arrays, ints, bools, …)
  • Solution 4: Restricted Abilities (aka Entitlements)
  • Solution 5: Provider Entitlements (backed by AMS, Bank Cores,…)
    • Boolean On/off
    • Numbers
    • Bespoke?
  • Solution 6: Enterprise Group Permissions (enterprise-authz)
  • Solution 7: Vault
    • Json (bool, number, arrays, objects, etc)
    • (Use file based where available)
  • Solution 8: bespoke app-specific configurations (specific to the individual service. example: check images, document providers, ACH, …). This can even be as simple as “if (bank) doThis else doThatCreditUnionThing”
  • Solution 9 (deprecated): Environment variables in the service
    • This is marked deprecated for business-facing configurations, such as a list of FIs who should be using some new feature.
    • Controlling domain names, which vault secret path to read, knobs on a http client, etc. are all still valid use cases. But that’s outside the scope of this Product/Business-case focused document.
    • see Solution 3 for business cases which currently get set as environment variables.
  • Solution 10 (deprecated): UX “Feature Flags”
    • These can be found here: /a/settings/{instShortId}/config/enterprise-config-groups
    • UX Admin own this currently and are killing off feature flag portion of config (to be replaced by launch darkly)

Notes about Permissions/Abilities/Entitlements

  • Many times these are used to tell clients what they should or should not show.

User Scenarios (Product):

  • Scenario 1: Enterprise User needs to enable/disable a feature for a specific End User.(Long Term usage)
    • Solutions: 1 or 5
  • Scenario 2: JH Employee needs to control a feature for a specific type of institution. (Long Term usage. For example, only available for a bank)
    • Solutions: 8
  • Scenario 3: JH Employee needs to do slow rollout/testing of a new feature with just a few FIs before making it Baseline.
    • Solutions: 3
  • Scenario 4: JH Employee wants to do a slow testing of a new feature with just a few specific End Users of an FI before making it baseline and available for all institutions.
    • Solutions: 3
  • Scenario 5: JH Employee wants to do a Slow Rollout of a new feature with just a few specific users of an institution before making it baseline and available for a specific set of institutions. (i.e. it is a feature that is only available for a bank)
    • Solutions: both 2 & 3 at the same time
  • Scenario 6: JH Engineers want to enable or disable a specific feature for limited-time internal testing
    • Solutions: 3
  • Scenario 7: JHA Product/QA/Operations/Analysts want to enable or disable a specific feature for limited-time internal testing
    • Solutions: 3
  • Scenario 8: End users to manage a feature for another user tied to their organization (i.e. a business admin can disable or enable rdc for another user of their organization)
    • Solutions: 5
  • Scenario 9: FI Admin needs to enable/disable access to a feature for another FI Admin in Platform
    • Solutions: 6 or 8
  • Scenario 10: JH Employee needs to restrict a feature for a specific type of institution while work to support the feature is planned/developed. (Ex: feature is not supported yet for banks but will be eventually. It could takes months or years until this support is added). Once the support is available the feature will be available to ALL users of that product.
    • Solutions: 8
  • Scenario 11: FI Admin needs to disable access to a feature temporarily for some End Users (for reasons such as fraud) and then decides to temporarily disable the feature for all End users at the FI. Eventually the FI Admin will wish to have the feature re-enabled for all users.
    • Solutions: TODO