Skip to content
This repository has been archived by the owner on Sep 13, 2022. It is now read-only.

Change "Relationship" to "Customer" #42

Open
trabianmatt opened this issue Mar 6, 2020 · 2 comments
Open

Change "Relationship" to "Customer" #42

trabianmatt opened this issue Mar 6, 2020 · 2 comments

Comments

@trabianmatt
Copy link
Member

trabianmatt commented Mar 6, 2020

The idea of "Relationship" seems to be a bit too abstract and leads to confusion as most of the APIs we're integrating use the concept of "Customer" and we find ourselves mapping those two conceptually.

Instead of using:

query AccountQuery {
  me {
    relationship {
      accounts {
        id
      }
    }
  }
}

We'll use:

query AccountQuery {
  me {
    customer {
      accounts {
        id
      }
    }
  }
}

Note that we're still keeping the distinction between "me" (as the current user) and "customer" (me in my role as a user). This is still an open area for conversation but we'll try this version first.

We still need to handle the idea of "Top Level Accounts" that we've encountered at FIs (particularly credit unions), where they'll have a structure like:

  • User
    • Account 1234
      • Subaccount 123401 (Savings account)
      • Subaccount 123402 (Checking account)
    • Account 4321
      • Subaccount 432101 (Savings account)
      • Subaccount 432105 (Loan account)

In a previous project we mapped these conceptually to:

  • User
    • Top Level Account 1234 (or "Account Group")
      • Account 123401
      • Account 123402
    • Top Level Account 4321
      • Account 432101
      • Account 432105

While most users only have one account and would thus be well served by a "Customer" that maps to a "Top Level Account", we can handle the multi-top-level-account scenario using an optional id parameter passed to the customer query:

query AccountQuery {  
  me {
    customer {
      accounts {
        id
      }
    }
  }
}

query OtherAccountQuery {  
  me {
    customer(id: "1234") {
      accounts {
        id
      }
    }
  }
}

Notes

  • While we'd typically maintain but deprecate the existing "Relationship"-related types, we're currently only using it in a single unreleased project and will update that project to use the new "Customer" type.
  • Despite the above, we should still bump the minor version of the package.
@trabianmatt trabianmatt self-assigned this Mar 9, 2020
@trabianmatt
Copy link
Member Author

I wrote out the documentation for "Customer":

  """
  The `customer` represents the user's role as a customer of the FI. It exists as a separate type
  from "User" and accepts an optional `customerId` because some banking systems allow users
  to have access to multiple "accounts", which then have "subaccounts". We attempt to reduce
  this confusion by referring to each of those "accounts" as separate "customers" and referring
  to the "subaccounts" as "accounts".
  """
  customer(customerId: ID): Customer

Does this capture what we're trying to do?

If we applied that same general documentation to "Relationship" would it change our thinking on which name worked best?

  """
  The `relationship` represents the user's relationship(s) to the FI. It exists as a separate type
  from "User" and accepts an optional `relationshipId` because some banking systems allow users
  to have access to multiple "accounts", which then have "subaccounts". We attempt to reduce
  this confusion by referring to each of those "accounts" as separate "relationships" and referring
  to the "subaccounts" as "accounts".
  """
  relationship(relationshipId: ID): Relationship

cc @DeathstarNovember and @treeme

@trabianmatt
Copy link
Member Author

Here's what other systems call the entity that has accounts:

  • CorePro: "customer"
  • Banno: "user"
  • FDX: "customer"
  • Stripe: "customer"

I'm thinking "customer".

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant