Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Think about how we can help people define organizations correctly #111

Open
3 tasks
jon-betts opened this issue Nov 30, 2022 · 0 comments
Open
3 tasks

Think about how we can help people define organizations correctly #111

jon-betts opened this issue Nov 30, 2022 · 0 comments
Assignees
Labels

Comments

@jon-betts
Copy link
Contributor

jon-betts commented Nov 30, 2022

At a high-level, what is the task?

  • Designing a set of separate entities for a customer you want to see
  • Ensuring the records exist in Hubspot for each entity
  • Ensuring there is an organization for each entity you want
  • Linking Hubspot Companies to those organizations by organization id
  • Finding all of the application instances related to each entity
  • Assigning them to the correct organizations

Things we are missing now

  • Ideally we should stop the rot before it begins
    • Our process should give us complete control over customer data from the start
    • This would prevent us from having to guess later
    • It also prevents good work being un-done / corrupted by automated assignments on new application instance creation
  • We have a difficult decision about how to arrange our organizations because we are missing hierarchy
    • If we have hierarchy we don't need to compromise
    • We'd have some interesting decisions and challenges to calculated numbers as a result
    • I suspect arranging orgs into a hierarchy is a simpler job than defining them

What we've learned about matching

  • You need a customer design in mind, before you can interpret the information you see in LMS
    • The same info might mean different things depending on your desired customer design
    • There can be no automated process, only tools & helpers
  • More recent info is more relevant than old info
  • We can't handle a single application instance being used across two entities we'd like to report separately on
    • ... but customers have an incentive not to do this, because they want the numbers too
  • There are some fields which are indicators of how to group application instances:
    • Tool Consumer Instance Name / Description (Application instance)
    • Tool Consumer Instance GUIDS - Although we are largely grouped like this already
    • Email domains (Application instance / group)
    • LMS URLs (Application instance / group)
    • Names (Groupings)
  • There are two types of general matching work:
    • Identifying application instances you don't know about which are related to the organizatios you are trying to define
    • Allocating those application instances between the organizations correctly

Small tasks we can achieve

  • Application instances should have a name we control, like organizations have
    • At the moment they only have what we get from LTI
    • This means even if we identify them, we can't give them meaningful names
  • We should show application instances in Report
  • We should be able to search groupings in Report (likely we'll get this as a part of course info)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants