Member Platform (Zoom) Meeting on September 25, 2025 [#3549063]

Google Doc

You might find the Google Doc for this meeting (from which the notes are copied) to be easier to consume and to include additional detail (e.g. comments) not present in this issue. If this meeting hasn't happened yet, find and add to the agenda in that doc anytime before the meeting.

Member Platform Meeting

September 25, 2025 at 10:00am CDT

Meeting Notifications, Agendas, Past Notes, Slack Channel

See [Meta] Member Platform meetings

Who is here?

Include your Drupal.org username in parentheses if you have one.

JD Leonard (jdleonard)
Paul McKibben (paulmckibben)
Mike Crawford (pelicani)
Bob Snodgrass (bsnodgrass)
Erica Stevenson (speckles)

What Topics Should We Discuss? / Limited Human Notes

Recording
Quick introductions
Review proposed high-level data model for CRM Membership, which will represent membership types, memberships, members, and dues paid

This is for post 1.0, but warrants some early input on the architecture
You can review code for a very early proof of concept (might not install) here
Membership Type (e.g. Individual/Standard/Premium)

ID
Label
Status
Organization
Contact Type
Default start date

Current day
Specific date (current month)
Specific date (next month)
Specific date (current year)
Specific date

Default duration

Lifetime
Time interval (must include calendar month as an option)
Specific date
Specific date (current year)

Membership (e.g. ABC Inc belongs to Chamber of Commerce)

ID
Label
Membership Type
Contact
Organization
Status (set of statuses not configurable)

Pending activation
Approved
Suspended
Expired
Pending cancellation
Cancelled

Is active (within window of start date and expiration date and status is Approved or Pending cancellation)
Created
Changed
Start date
Has expiration date
Expiration date

Membership activity (generated by plugins e.g. dues paid)

Timestamp
Membership
Membership activity type
Acting Contact
Acting User
Message

Member (e.g. one entity for each employee of ABC Inc)

Membership
Person

Examples of membership scenarios with expiration dates

I’ve never been a member and join

Create Membership entity

I renew my membership such that it will remain active contiguously

Update Membership entity expiration date

I renew my membership such that there will be a gap

Create new Membership entity representing the future membership

I renew my membership but of a different Membership Type (e.g future upgrade)

Create new Membership entity representing the future membership

It’s 2025 and I am a 2024 member

There is a Membership entity expiring Dec 31, 2024

I renew my membership starting in 2026 such that there will be a gap

Create new Membership entity representing the future membership

I then renew my membership for 2025 (backdated to Jan 1, 2025) such that there will no longer be a gap

Update 2024 Membership entity expiration date
2026 Membership entity remains, despite being contiguous with 2025

Three

I am a current member

There is a Membership entity

I then “change” to a different Membership Type

Update existing Membership entity expiration date to expire early
Create new Membership entity of the new Membership Type

Four

I am a current member

There is a Membership entity

My membership expires or is otherwise cancelled, suspended

Update Membership entity status

(time permitting) Work session on mockup requirements and/or functional specification

Action Items

Fathom AI Summary

VIEW RECORDING - 203 mins (No highlights)

Meeting Purpose

To discuss and refine the CRM membership data model and functionality for the Member Platform project, focusing on membership entities, types, activity logging, and related processes.

Key Takeaways

Topics

Membership Entity Structure

Membership Activity Logging

Membership Types

Renewal and Changes

Edge Cases and Considerations

Next Steps

Fathom AI Transcript

VIEW RECORDING - 203 mins (No highlights)

@0:02 - Mike C

That's what the future holds.

@0:05 - JD Leonard (modernbizconsulting.com)

Thanks for joining all. I think we've all introduced each other, introduced ourselves to each other before, so we can probably skip along to CRM membership.

I will share my screen. I will also add a link to the meeting notes in the chat. You can add yourselves there.

SCREEN SHARING: Jd started screen sharing - WATCH

So, Stephen Ayers, the maintainer of CRM, has started thinking about a CRM membership project and, you know, how to represent memberships, right?

So obviously, this is key to a member platform, and he's not able to be here today, but I think his intention is to kind of start it, kind of get a proposal out there, and then probably hand it over to us to, you know, take forward.

I think it's notable that we don't need this for member platform 1.0, right? But, and the reason for that is because we don't need to deal with anything more than a lifetime membership, right, for our 1.0 scope.

But I think shortly after 1.0, we're going to want to expand upon that pretty quickly. And so I think it is worthwhile to, you know, spend a little time just trying to get this right from the start, particularly while Steve is going to help us, you know, get things moving.

Hey, Erica. Hello. So we're talking about CRM membership, and I'm going to do my best. To convey what Steve has come up with here, I had a call with him yesterday to go over this stuff, and I think one of my goals for this call is to get everyone thinking heavily about, you know, will this represent, be able to represent all the things that we think we need to represent when it comes to membership.

So I did put a link in the notes here to some code. That might not even be the best link.

Maybe I should update that with this. Not going be a better place to go. Let me do that. And we might switch over there in a minute.

And everyone jump in whenever you think of something. So first is the concept of a membership type, right? So this would be, for example, an individual membership.

Or an organizational membership, or a family membership. It could be like a standard membership, a premium membership, right? Conceptually, it's like, well, what, there has to be something different about this membership.

And notably, it is specific to an organization and a contact type. So the proposal here is a membership type does not, cannot span multiple organizations or multiple contact types.

So you, if you have a membership, it can't, you know, work for both a person and an organization. Status is kind of like an, is this active, I think.

We need to, they're defining. Exactly what status means when we use it places, but, and then there's some sort of concept of duration, possibly, I think it's sort of an open issue about where this belongs exactly.

@4:17 - Paul McKibben

So what sort of use cases have been thought about for this? For what I'm doing with the Atlanta Drupal Users Group, a lot of this really doesn't, is more than I would need.

It's, know, but I could see for like organizations that have paid members, for example, that have to renew every year or, you know, that sort of thing is where this could come in.

Or like maybe your homeowners association has, you know, dues paying members or something that need to be accounted for somehow.

@4:46 - JD Leonard (modernbizconsulting.com)

Yeah, so some use cases that have been discussed include, yes, obviously paid memberships is a big part of this with different durations.

That's so One. There's, you know, probably a concept of fixed versus rolling, you know, membership timeframes. We've discussed that there needs to be a way to represent, you know, a membership being canceled, a membership being changed to a different type of membership.

I think what else we discussed.

@5:28 - Paul McKibben

That's a good use case that actually could apply to me, is, you know, somebody who's been a member and says, I don't want anything to do with you anymore.

I want to cancel my, you know, membership. Don't email me ever again, but you want to keep history that they were a member.

@5:43 - JD Leonard (modernbizconsulting.com)

Yeah, we also talked about, you know, you might be, yeah, you might have gaps in your membership over time, right?

And what else? Is the idea that you'd create a new membership entity.

@5:59 - Paul McKibben

Is Each time they renew, for example, with a new timeframe or?

@6:04 - JD Leonard (modernbizconsulting.com)

Yeah. So that's a, that's a good question.

@6:07 - Paul McKibben

Yeah.

@6:13 - JD Leonard (modernbizconsulting.com)

So membership is the, this membership has a membership type. Right. Yeah. Membership is an, you know, a representation of a membership between a contact and an organization.

That contact could be a person, a household or another organization, right? Imagine a chamber of commerce that has other businesses as other organizations, as its members, right?

So when. Somebody goes, and for now, right, in some sort of external billing system and pays for a membership, right?

Regardless of who that membership covers, it results in the creation of a membership entity, right? And this contact basically represents the kind of the, like, primary contact for that membership.

It's probably who paid for it, right? Then there's a second layer here, right? So once you've got this representation that there is a membership, then there will be a member entity that represents, each member entity will represent each contact, each person that is covered by a membership.

Okay. So... So this affords for flexibility in having a membership cover more than one person. It affords for a membership that covers, for example, all of the employees at an organization.

So I'll let that sink in and feel free to...

@8:23 - Paul McKibben

The membership duration, we need to account for the idea of lifetime membership, I imagine. So that duration might not just be a set of dates, but might be...

My association has a lifetime membership option.

@8:45 - Mike C

Yeah, these different options become... Now I'm looking at this data differently. Originally, I was looking at it as a record of the membership, but now membership type becomes something else.

That isn't the actual membership. It becomes a definition of what the membership is. you could have, like you're saying, different types of memberships for different purposes that then you could have memberships off of that.

So you would have, like you said, company access. So its member wouldn't be tracking the number of people. That type of membership really doesn't matter how many people there are.

They're not going to get individual emails. They're going to get one thing that a bunch of people access. Would that be an example of what a company membership is?

Or is it merely the paying mechanism, but everyone still has all their own access through the company? How flexible is this type and how complicated are we going to make this versus like an organic groups method where we're anticipating this product having multiple groups that we will eventually get towards where now we just need a membership that ties which group you're a part of, what's your status, and all those other things, which could be done with like workflow as far as status for the membership.

That's already been done that we would emulate.

@10:31 - JD Leonard (modernbizconsulting.com)

So I think the key differentiator, right, between what has already been done in this realm and CRM is the representation of everything as contacts, right?

So almost nothing that we're talking about here has anything to do with users logging into the system, right? We are right now focused on just representing the facts about memberships and who is covered by memberships.

Right. Sort of more abstractly. Who would get information from the membership, right?

@11:04 - Mike C

You would be able to personalize it for how you personalize that membership.

@11:11 - JD Leonard (modernbizconsulting.com)

Correct. So a, let me try to type this out. So a member entity, right? Okay. Well, let's take an example of ABC Incorporated belongs to a chamber of commerce, right?

Right. So there is a membership representing an organization being a member of another organization. And I think we actually can ignore, right, for the moment, whether chamber of commerce is like, it's their website that we're on or not.

Right. Because this could be used in any number of different ways. It does not assume that chamber of commerce is represented by this, this website.

Right. But for member platform, we're saying probably for a while, we're focused on a single organization's website. Right. But you could imagine that organization might have some use case for tracking, I don't know, the memberships of other organizations, and CRM membership would support that, even if member platform maybe decides to hide that or put some of that out of view.

So we're kind of thinking right now beyond the scope of just member platform and about what are all the different use cases to how we could represent memberships.

@12:30 - estevenson

Yeah, so if I were to think of like a smaller scale sort of thing where you had slightly more complicated, something for a daycare where someone has two kids, so the mom has a member, so that would probably be associated with household.

But then, yeah, like it would be the two kids would be the sort of members. So mom would be receiving kind of the email, even if kind of for the purpose of tracking, the membership kind of affected the two kids.

So yeah, that might go to a household entity. So that, that's.

@13:11 - JD Leonard (modernbizconsulting.com)

Yeah, so just continuing back with the ABC Inc, right, example. So if ABC Inc has five employees, right, and the Chamber of Commerce says, hey, this membership, you know, is a membership for the organization, and it means every employee gets some sort of benefit.

I don't know, they can attend meetings or whatever it is, right, then there would be five member entities representing the five employees of ABC Inc, and these could be automatically curated, right, based on a plugin that would ship with this suite, right, that would say if there is a membership type, for

You know, this chamber of commerce, right? It would be configurable to cover the employees of the organization, right? And so when the membership gets, you know, added here, it could automatically create five members.

I mean, obviously, you need the information about these people in the system, right? For this to all fit together.

So don't think too hard about, like, the complete feasibility of all this, right? Like, takes a few steps between talking about this and, like, it all coming to fruition, right?

But conceptually, you could do that automatically or have it be manually maintained. But just the point is, we need a way to represent this, right?

Also, what if ABC Inc.

@14:47 - Paul McKibben

has, say, instead of five employees, 50 or 500 or 5,000 employees? Would we want an option to just not include the individuals at all?

Maybe just some tea?

@15:02 - JD Leonard (modernbizconsulting.com)

Yeah, so that goes back to the configuration of the membership type in this theoretical kind of plugin system, right?

You wouldn't have to choose the option for covering the employees, right? You could treat it as just purely, you know, membership for an organization to another organization, and there's no complexity kind of beyond it.

@15:24 - estevenson

Um, what about this scenario, where kind of like, as an organization, maybe I have two levels of membership, one of which affects 10 members, and one of which affects five, but you're kind of I as an organization have kind of like bought both.

So could you, does this handle kind of the case where I've bought kind of a, yeah, I have a membership, but it only affects kind of a subset of the members associated with me, if that makes sense.

So I heard kind of two things, right?

@15:57 - JD Leonard (modernbizconsulting.com)

One is having two memberships. There's no problem there. Conceptually, they probably should be of different membership types, because I don't know what it means to have duplicate kind of memberships, right, of the same type.

But what you described was one membership that covers all the employees and one that covers some of them, something like that, like a premium membership for the executives or something like that, right?

@16:20 - estevenson

That's what I was thinking, that scenario.

@16:22 - JD Leonard (modernbizconsulting.com)

Yeah, there's no reason that they can't represent here. Mm-hmm. So I've actually got a dash for about five minutes.

I'll be back, but would y'all keep talking this out and take some notes in here and kind of figure out what's missing?

You can refer to the code to... I was going to have to drop in a few minutes anyway, so I feel like this is good time for me to just go ahead and do that.

@16:47 - Paul McKibben

All right.

@16:47 - JD Leonard (modernbizconsulting.com)

Thanks, I'll be back in about five minutes, everyone. Sorry for dropping out here. Have a good day.

@16:57 - Paul McKibben

See y'all later.

@22:00 - JD Leonard (modernbizconsulting.com)

Let me share my screen again here. Do we have any thoughts while I was gone?

SCREEN SHARING: Jd started screen sharing - WATCH

@22:04 - estevenson

Oh, kind of. So I ended up writing down two thoughts. One that, you know, kind of, think is entirely out of scope and different project, but came to mind is something like a membership case manager, where kind of like, I have these memberships, and they kind of entitle you to have a kind of like a worker associated with it.

So like, yeah, like I bought a sort of special time with a teacher for kind of like my kid.

You know, kind of like, so, I mean, that is not who belongs to a membership, but it is kind of who a membership is assigned to.

And I think that's out of scope. But if I'm trying to think of things that I might associate with membership, you know, kind of like you could have a member associated that way.

That's interesting.

@22:53 - JD Leonard (modernbizconsulting.com)

So Steve is working on CRM Case, which is a case management solution built on top of... CRM, don't know if that's exactly what you were describing.

@23:03 - estevenson

Yes, no, no, no. It felt like something that would be out of the scope of this and something that would be a different module.

But, you know, kind of, yes, just sort of touching on that. And then the other thing that came to mind is what about the concept of an alumni type membership where, you know, kind of like you could represent this by just having kind of a second relationship kind of created.

But, you know, because we're talking about that where, yes, you kind of get an introduction. So, like, I'm thinking, yeah, that you have sort of programs where, you know, kind of you get someone actively working with you for three months and then that time is done.

But then you still have access to some resources within the organization. So kind of like your test scores or whatever.

@23:47 - JD Leonard (modernbizconsulting.com)

So I think the concept of, like, some sort of more normal membership followed by some other type. of membership is certainly possible, right?

I think it's just two different memberships of two different types. Yeah. Also, what I think is interesting, right, is some of what you were describing kind of just describes relationships.

And CRM has a concept, right, of relationships between different types of contacts that, you know, is not a membership, right?

But depending on what it is you're trying to do, you know, you might not need a membership. You might just want to represent that somebody is, you know, an alumnus of the organization.

@24:37 - estevenson

But, know, kind of like, I'm just thinking with a temporary membership, you might want to have known who is managing the person at this time, even if later on that person gets assigned to something else or is no longer assigned.

You know, like, again, like, I don't necessarily think that this is the right thing, but...

@24:55 - JD Leonard (modernbizconsulting.com)

Well, or even something like a sales rep, right? Yes. Right?

@24:59 - estevenson

It's sort of a...

@25:00 - JD Leonard (modernbizconsulting.com)

An analogous concept. And I think for those kinds of use cases, right, the answer is, well, membership is fieldable, right?

So if you need a field to represent some additional thing, you're treating better, yeah. Yep. Good thoughts.

@25:21 - estevenson

Ah. So yes, no, that was me just sort of, yes, trying to think of stuff. I'm going to sort of, I mean, it sounds like they're both resolves, so I'm going to delete them both, but.

Cool.

@25:32 - JD Leonard (modernbizconsulting.com)

So let me bring up something else that Steve and I were discussing yesterday and trying to wrap our heads around.

Um, so, uh, you can imagine that a membership entity, and the concept here that Steve has proposed is that for a given, uh, for a given contact who is a member of an organization, um.

No, sorry. There is one membership, right, to represent a membership of a contact to an organization. And if that person, say, renews their membership, right?

Steve is proposing that that does not create a new membership entity to represent that, but rather it modifies the existing membership entity to, you know, extend the expiration date of your membership.

And there would be a separate concept, and the naming is not liked, but of like dues log or some other thing to represent, hey, you made a payment for your, you know, dues or whatever it is you're paying, right, for, you know, maybe a membership for a certain period, right?

And that would be immutable. It's like you create the dues log entry, like, hey, somebody paid their dues, here's the amount they paid, you know, here's what it was for, here's maybe an external billing system reference if you need it, or something like that.

But that membership kind of represents their contiguous membership. Mm-hmm.

@27:20 - estevenson

So yes, membership would be mutable in order to sort of allow for extension. But there would be kind of a separate logging table for, you know, kind of like you have changed sort of that.

And I'm just sort of thinking of other scenarios, like maybe you have kind of a thing where members regularly kind of vote for kind of someone to continue a particular membership type.

That seems like a weird scenario, but yeah. So the voting, that kind of sounds like there's sort of like a workflow associated with voting that would result in memberships being modified, right?

Yeah, I wouldn't, I wouldn't sort of, like, yeah, I'm just trying to think of some... And I would still imagine that happening offline.

I'm just sort of thinking, like, what is a different scenario where someone would want to have a dues log, where you have kind of like, you regularly have outside of the system a competition, and you kind of, and you have to sort of win the game of Yahtzee in order to continue kind of.

@28:22 - JD Leonard (modernbizconsulting.com)

One example was, you may have historical data that you want to import, right, into the system about dues payments and things that you don't necessarily, you're not able to populate the system with the historical membership types and memberships and, you know, all of the information.

So it's a way of still associating some sort of history with a contact, right, about their membership. So it's not yet clear exactly what dues log points to, right?

If anything, like certainly the contact, right, would be referenced, but it's unclear, like, does this reference a membership? Maybe, maybe it's optional.

@29:15 - estevenson

I mean, if it doesn't reference a membership, then is it a dues log? Or is it just sort of like, you know, kind of member sort of history?

Well, just take the example of historical data that doesn't have a membership to reference, right? We at least want to be able to handle that case.

@29:40 - JD Leonard (modernbizconsulting.com)

One of the more complex scenarios that Steve and I talked about yesterday that I don't think we fully resolved how we deal with is sort of a sequence of events where, let's say you are a 2024 member, right?

of some organization that ends. at the end of the calendar year. And now it's 2025. You're not currently a member, right?

Your membership lapsed. So you have this membership entity, and the expiration date is in the past. Right? And, okay, well, let's say, let's say now you want to, I'm going to do a simple one first.

Let's say now you want to renew for 2025. Right? Okay. We can just extend the expiration date here and add a dues log entry.

@30:34 - estevenson

Right?

@30:35 - JD Leonard (modernbizconsulting.com)

And you're kind of covered. Right? But back up, let's take a more complex example and say, it's November 2025.

@30:46 - estevenson

Right?

@30:47 - JD Leonard (modernbizconsulting.com)

You were a 2024 dues member. You don't want to pay your dues for 2025. You've only got a month left or something.

Right? And you want to pay for 2026 dues. An organization could support that. mean, my neighborhood association deals with that.

Like, in the last three months of the year, you can pay for your next year's membership, regardless of your current status, right?

How do you represent on the membership entity, right, that you are not a current member, but that you have a future sort of pending membership coming up?

Yeah, no, I could see that.

@31:24 - estevenson

Because yes, people sort of pre-signing up on stuff.

@31:30 - JD Leonard (modernbizconsulting.com)

So what we kind of came up with, and I'm not sure we're convinced this is the best way to do it, is you would have a join date that's like when you were first a member.

I don't know if any of you have an American Express card, but they always put member since on your credit card, right?

It's not the start date for that credit card necessarily, right? It's the start date for when you first, you know, had a relationship with American Express.

@31:53 - estevenson

So similar concept here.

@31:55 - JD Leonard (modernbizconsulting.com)

It's like, well, when were you first a member? And then the... The membership entity would reflect the start date of your current membership, kind of, right?

Or if you do not have a current one, your future one.

@32:14 - estevenson

Okay, so yeah, so now I'm just trying to think that inside practice. So yes, when I initially signed up and had that year of 2024, that would have a start date.

And then kind of like, when I apply inside November 2025, because I want something for 2026, it would overwrite that the start date of that original membership?

Yes.

@32:37 - JD Leonard (modernbizconsulting.com)

So, I mean, membership would be revisionable, there'd be past revisions that kind of capture what it was before, right?

But that yes, that's the idea.

@32:45 - estevenson

Mm hmm. Yeah, like, I'd almost be tempted to do something like activation date instead of start date, just because, start date, start And I think the start date, the idea is it would represent...

@33:00 - JD Leonard (modernbizconsulting.com)

Represent the time that you started this membership contiguously is sort of the idea, right? So it's not that this membership, it's not that your membership is for 2024 or 2025 and thus the start date reflects that, right?

Okay. It's when did you, when was the active membership originally started? Yeah, no, no, no.

@33:35 - estevenson

Like the closest thing I can think of to an objection to that, because yeah, like, mean, the concept makes sense is like later on, I am trying to learn this sort of module so that I can kind of do my own thing.

And someone sees start date and then they get confused, which, I mean, could just be a matter of documentation, but, you know, kind of is start date the best sort of name for that concept?

@33:58 - JD Leonard (modernbizconsulting.com)

Well, so I think there's also some... Additional complexity here, right? What if, let's say it's, let's say you're a 2025 member, and your, you know, membership entity reflects, or let's say you're on a monthly membership.

And, no, that's a bad example. Let's say an organization allows you to decide when a membership starts. And let's say you just have an annual membership, right?

So maybe I started my membership in October of last year, and it's September of this year. My membership has not lapsed yet.

So I have a current membership that's going to expire in October. And I want to pay for a membership that starts in January, because I'm going on vacation or something.

I'm not going to use my membership, right? Conceptually, an organization could allow that for that kind of thing, right?

So how do we represent that?

@35:09 - estevenson

I mean, like my immediate sort of guide is that that should somehow be kicked out to a new table, just because like, I mean, that means that a membership can have multiple start dates.

So like, logically, that means, yeah, that means it's a many thing. Because yes, I could have kind of a start date, because my membership is current, and it's going to expire.

And then for that membership, I also have a different start date. So I don't know, to me, to me, that says different table, and that's sort of associated back to this one.

@35:46 - JD Leonard (modernbizconsulting.com)

So what's, what's confusing to me, right? So I had, we had this discussion, I had this discussion with Steve yesterday, and then we talked about this dues log, because what a dues log allows you to track separate from what we do.

Just discussed, right, is, hey, I made a payment, that payment could be for zero dollars, right, or currency of your choice.

doesn't have to be a paid payment, right, conceptually purchased it, well, even if there's no price, right. For, so you've purchased a membership, it's for a certain start date and end date, right, that's what you paid for.

And so that would easily represent the concept of past, current, and future, you know, memberships that have been paid for, right.

There's no complexity there. And then, so it got me thinking, well, okay, what are we trying to accomplish, right, by tracking this sort of start date, join date, expiration date for membership, right.

Right, we do have this, we do have this need to understand for a given. Right. Person, right? Or contact.

What are their active memberships? We'll have a desire to say, I want to look back and see their history of membership over time.

I need to understand any future memberships that are coming up.

@37:16 - estevenson

Yeah, like another scenario that just popped inside my mind, but what about kind of a paused membership where I have paid for three months on kind of midway through the second month, I decide that, oh, like I won't, I'll be going on vacation.

I want to pause it and then have kind of that month rollover. So I want the end date to change.

And my sort of membership isn't active for kind of like this month. Um, like, is that something that kind of, cause yeah, that, that, that is starting to get complicated.

So yeah, is what, what, what is that a scenario that we want this to support? And if so, does it support it?

@37:56 - Mike C

Right. mean, I'm listening to a lot of this and a lot of it sounds like fine. financial reasons to suspend your, you know, you want to, if this were a free membership, then there's, the only reason to suspend it was I don't want to get an email or included.

And that could be a different trigger as far as status or something. But like, if a lot of this is because we want to delay, we want to maintain the 12 months of our membership, but we're allowed to expand that over years, then shouldn't this be like a completely separate thing that is done through a commerce solution, that, that then becomes way more challenging to integrate into a commerce solution and well beyond something we'd be able to tackle at this point.

@38:46 - JD Leonard (modernbizconsulting.com)

I think it's a good question about, Hey, what, what is in scope here versus a billing platform?

@38:51 - estevenson

Right. Yeah.

@38:53 - JD Leonard (modernbizconsulting.com)

And I had a similar discussion with Steve yesterday. Um, and And where I think I'm landing is I think that this should be able to represent sort of information about the membership, right, that an organizer in the system is going to want to be able to access and view and understand.

So to the question of a paused membership, I don't think that this system needs to handle all the mechanics of pausing, right?

But I do think that it needs to support the concept of a membership being paused and just representing that it is paused, right?

And that doesn't necessarily need to be out of the box, right, support, but at least you could add a field that's like a flag saying is it paused, right?

Or if you have workflow states associated with a membership, one of them could be paused.

@40:00 - estevenson

Mm hmm. Right.

@40:03 - JD Leonard (modernbizconsulting.com)

I don't, I don't know about, obviously, there's a lot of business logic involved. Yeah, no, no, no, it's a whole rabbit hole that we don't really need to dig into.

But, but I think we could say that, okay, external billing system or manual intervention, right, is necessary to, to determine when something is paused and unpaused.

Yeah.

@40:24 - estevenson

kind of like, yeah, and you could have that the dues log handles the complexity around that. So a membership is paused and then kind of I add whatever auditing kind of like logic I want inside the dues log.

And then like have sort of whatever business rules I need in order to update the table. Pause date or kind of other date.

So I'm not actually, I'm not convinced that the dues log should track.

@41:02 - JD Leonard (modernbizconsulting.com)

Yeah, no, I would agree.

@41:05 - estevenson

I think if that concept is needed, that's probably a field that gets added to the membership, right? I don't know that we...

Actually, doesn't status cover that? Because, yeah, you could have status paused.

@41:22 - JD Leonard (modernbizconsulting.com)

Status is presently conceived as the sort of default Drupal representation of status, like a one or zero. But personally, I don't love the use of that, because I think it's such an overloaded concept.

It gets very confusing and right for misuse.

@41:43 - Mike C

So calling this dues, again, makes me think of money and commerce. And there isn't anything about history here. I kind of see history as what we're doing.

And dues, again, should be reserved for commerce. And it shouldn't, we shouldn't really deal with... And with that, could easily add like an event that anything could subscribe to to track history or do something to the process of something within our system happening to a membership to track member history.

So we could have a default member history that, hey, this action happened at this day to these records. And we can have an event to allow anything to tie into this to say, hey, if it's this action, we'd like to record the commerce thing or whatever, and let those modules manage whatever they do in the whenever something happens within our module.

We just want to track history, not necessarily dues. That would be a separate event subscriber that we could write.

@42:52 - JD Leonard (modernbizconsulting.com)

I completely agree about the event-based system and allowing, you know, other things to plug in and react. And so on and so forth.

But I think I disagree about not tracking anything related to money in the system. And my reason is this, right?

So when you're thinking about the membership of somebody, it may be very relevant information to you as a volunteer or staff member of an organization to be able to quickly understand, hey, when was their last payment?

How much was it? You know, maybe you're doing some sort of customer service around this. And to have to potentially switch into a completely different billing system to look it up is sort of like a bit of a lift.

So I'm not proposing that we implement a billing system, right? Just that we have a place where you can effectively just copy some basic information about payments that were made, so that it's available in one system.

And also because you could imagine an organization could have... They billing systems. They might have one for credit card payments.

They might have another for bank transfers. And they might have another for in-person cash payments. You may not have a single system that covers all of that.

And so being able to centralize this.

@44:14 - Mike C

But it's all commerce. I just thought of kind of something I remember that could be kind of like different.

@44:21 - estevenson

But I remember at one point going to a sort of like camping LARP where they kind of had the concept that you could pay or kind of like you could have you could accumulate enough volunteer shifts because they needed people, you know, because it was a LARP.

They needed people to act as the bad guys. They could be hit with sticks, you know, kind of like and you could sort of volunteer for X amount and gradually kind of like so that acted as a separate credit within their system, like spent time volunteering.

And then you could accumulate enough credits so that you that that counted as paying. So you could either do that kind.

Kind of as, yeah, maybe you go to sort of one thing and you're entirely a volunteer and you're able to just sort of like then pay that for the next camp where you get to just be a participant or they also had the concept that, you know, kind of you have X number of shifts and then that pays for this one.

So that's a slightly weird example because, yeah, that was always sort of handled on paper because it was their thing.

But that is an example where you could have a currency that's not money.

@45:32 - JD Leonard (modernbizconsulting.com)

Yeah, I mean, I think that's a good example, right, of, I mean, I'm thinking further down the line here, right, there may be some value in being able to aggregate some financial information into a report, right?

And the idea that there might not be a single billing system that captures all of those things, right? And for for

A lot of these small organizations, these under-resourced organizations we're talking about, their books might be being done on a spreadsheet, right?

Like it might be very, very basic, like their accounting. So just providing some structure to allow them to track some information to make their life easier is kind of what I'm thinking around here.

It's not supposed to be like a fully-fledged solution that meets all sorts of different use cases. But just a quick at-a-glance, like when I look in my CRM, I should be able to understand that somebody paid something, right, on a certain date.

@46:38 - Mike C

I think I'm at it. I think I need to – I'm trying to look at the CRM membership code to see if that tracks history for the memberships.

Membership would have a revision history, yes. Well, that's not. Like history itself, again, so CRM, not CRM, commerce, yes, a full-fledged commerce solution that is about dollars, if that makes sense.

What you're introducing is we just want something that we can manually enter in this information to track this stuff.

But it's still commerce-related, and it still would be built as a plug-in. It wouldn't be the full commerce thing, but it would be its own thing.

The fields would show up, you know, the UI would be as if it was written into this, but it would still be a plug-in.

The ideas that we still haven't gotten is that plug-in thing that would be the history, because all of those things would fire when we track history.

We would just call an event, and they would have a subscriber that said, hey, in this case, we're tracking this information about dollars that we're injecting into this entity.

And we're building off of that. When this... This happens. If this exists, process this. And also this module would also include, when displaying this entity, include these fields because it's important and it's part of a relationship to it.

But it's not the core system. Most people aren't going to use this. Everyone's going to track history. Everyone's going to want to see when something in the membership transpired and what it was to be able to generate a report of all those pieces.

Now you can generate a report that just does the finance stuff, but everyone's going to need the history. And once we have the history, it can use events to use these plugins to display other information.

So you're making a lot of sense to me, Mike.

@48:46 - JD Leonard (modernbizconsulting.com)

Can you better define what history is?

@48:50 - Mike C

History is going to be when you log in and you go and you want a membership. And you pick the one that's delayed.

A delayed one is going to have to change the status. So you pick it and you subscribe to it.

Now I've just joined. I've created a membership, but it hasn't started. So I have different statuses throughout history of what's happening, different actions.

I've joined. And if we're just talking membership, it's going to be the history of that membership. So me, I guess joining would be, it's not going to track me logging in or anything like that.

It's going to track the status of the membership, when it becomes active, when it expires, and it'll track when those things happen.

And we'll have like a cron thing that runs to update the status of the memberships. We won't necessarily require a person to log in to have that happen, but it's going to check then too.

And it's going to manage that membership. It's the history of when everything happens. to that membership entity, or a membership entity is created, or a workflow status changes, or you have a plugin that changes the fee automatically a year into their membership, which lasts three years, and it updates or it doesn't update because they have a membership status that doesn't handle that.

So all these pieces we talked about are going to be logical elements to this history transaction. That history transaction is going to determine which of those pieces, or those pieces determine which get fired, but that event is that history.

What happens to the membership entity? Anything that happens to it, it gets tracked as history. It's not necessarily revision, but it's a...

@50:45 - JD Leonard (modernbizconsulting.com)

Yeah, I'm trying to understand the difference between this history and the revisions, which are the changes to, or the history of the membership entity.

A revision is merely a change that you...

@50:56 - Mike C

it's storing for you, so you can go back and... You're not going to run a report off of that.

A membership history is tracking a specific action that's happening, and it's going to give it a date, it's going to give it a user, it's going to give it a relationship, and you can generate reports off of that, not what changed inside of the entity.

We're tracking any relationship of this entity that changes.

@51:24 - JD Leonard (modernbizconsulting.com)

This is kind of like a Facebook activity feed, right, of things happening related to the membership.

@51:32 - Mike C

But it's really, like, I manage a couple group implementations, and even the other, even we have a membership, we have a, it's not membership, but it's, you subscribe to it, and then you get access to do things.

And when you, those things are very related to these memberships, you're joining something, and tracking the action in both of those projects that we're working on.

Tracking Tracking that history has been really important for the overall management of the site to see what happens. And it's been very useful for us to define the actions that we're tracking and the relationships throughout so that we can look at that stuff.

In addition to all the things you're saying, like those are the features that you're giving them. And this history really is not a feature.

It's an admin tracking for us to see what's happening, where any irregularities. It's been very useful.

@52:33 - JD Leonard (modernbizconsulting.com)

Does this live on the contact, on the membership?

@52:39 - Mike C

Well, the beauty of this is the log itself could be used for any entity in the site and what it does.

But we would just introduce it at this point. We're just talking about memberships. So when a membership entity changes, not a type, not a member, but when a membership entity...

If has a relationship that changes, we could track that.

@53:03 - JD Leonard (modernbizconsulting.com)

Would you also want something similar on the member entity that tracks the connection between a membership and a person affected by that membership?

@53:15 - Mike C

It would depend on those relationships and what happens to the member. don't think our member is going to have anything to it other than that it exists and that it has data.

I think a revision would be useful for that. The membership is going to go through states and statuses. It's going to go through a lot more than a member because that membership is tracking all of that action, all of those statuses, all of those states.

The fees are going to be tied into it. Everything is going to be tied into that membership. And that type is very interesting because that changes that membership and how it reacts to things.

So those those membership times. Types are going to have event subscribers that tie into the history that allow it to do what it does to the stuff instead of the other things, the default stuff.

So I kind of see that membership type and is a, so the membership is, that's the meat, that's the product, that's the burger you're going to eat.

Like that's the thing that you ended up with. It changes. Everyone's got a different one. And you're going to get it at different times, but what goes on it, that's the type, that's the, you know, probably a horrible analogy.

Okay.

@54:36 - JD Leonard (modernbizconsulting.com)

So membership history could be populated by plugins and other stuff that react to events.

@54:46 - Mike C

The opposite. Membership history is the cornerstone that everything will plug into.

@54:53 - JD Leonard (modernbizconsulting.com)

Is, okay, so help me build out what is, what, like, what would you stick in a membership history table or, or, you know, what, what are the columns?

I'm still trying to wrap my head around how this is different than just revisions of a membership.

@55:05 - Mike C

Again, a revision of the membership shows all the changes to the membership, the entity of the membership.

@55:12 - JD Leonard (modernbizconsulting.com)

It's not going to show you a change to a reference to...

@55:17 - Mike C

Actually, it will... You can inject that. I don't know if it... I mean, you'd have to inject that into the log.

But once you have that revision log, you don't use it. You don't query it. don't... It's not...

@55:34 - JD Leonard (modernbizconsulting.com)

Well, I mean, you can, right? I mean, I've definitely created views that list revision information from revisions of entities.

I just feel like we're convoluting the revision log if we're going to track...

@55:50 - Mike C

Like the history of that membership.

@55:54 - JD Leonard (modernbizconsulting.com)

I mean, literally, like the revision... And revisions of an entity track the changes to that entity, right? And I keep hearing that the membership history is about tracking the changes to the membership.

So I'm struggling to... I completely understand that it is sometimes hard to deal with revisions.

@56:18 - Mike C

If you change a workflow status, yeah, it is. It's really difficult. And it would be easier just to allow revisions to change the entity fields when you change them, editing a membership versus tracking changes to the memberships, workflows, and other relationships and other things and tracking those that you can then define.

And once you have a history of all of those things happening, all of the things, all this changes, like, you're not just saving the membership.

You're going to save state to the membership, so the membership entity doesn't change, still pointing to the same reference, that reference changes, right?

But you want those in the history of the membership, and you don't necessarily want to write that to the revision of the membership, or maybe you do, I mean, that's part of the conversation, is when this happens, track it, put it down somewhere.

So if we have a membership type that changes, it may affect the memberships that all exist, and that would affect, if it does, it would affect the history.

But the revision of the membership would never change unless we manually did that, which is fine, it's just putting a lot into the revision state.

Whereas if we tracked the fact that a membership was saved, we don't care what changed, just that it did, that's history.

It was edited, that's history. We don't care what. Change, just it did. That's updated. It was deleted. We can track.

We don't necessarily need to delete it. It just goes into a deleted state. It's deleted. We can track that in history.

Not anything else other than date, who did it, you know, basic stuff. But we also have these moments where things are happening and we can create events for each of them so that when we're writing plugins, we can write subscribers for each of these events.

We can have a document editing. You you can do all these different pieces of the membership change so that they can have a reference that creates their own within the system.

But the history is the back, but it's the piece that everything's going to, because we're going to write this and track each of these actions, this is where anything is going to want to plug into.

So it becomes the logging becomes the... P.I. requests or something that ties into this membership stuff. Erica, what are your thoughts on all this?

@59:08 - estevenson

Oh, like, I mean, I would love a more concrete kind of, like, example of what's being described, because I know I'm struggling to sort of, like, follow along, particularly because I'm newer to sort of Drupal.

@59:20 - Mike C

I mean, you know, save, update, you know, CRUD entries all would record an entry record in the history. Every CRUD, a create, edit, delete, you know, they would all generate a record, date and a time.

But it wouldn't record what was changed. That's not important. It's just the fact that it did and what it was.

@59:45 - estevenson

Also a little bit confused how this ties back to events that, I mean, the do's, if I were to sort of think of it a different way, is we want to track membership events where, yes, kind of that I signed up.

To kind of. For future membership, or I did this, that we don't, like, yeah, that, I mean, we're trying to, I'm trying to sort of, like, trace this back to the thing that we're, that, yes, the events that we care to track, and just sort of, yeah, I'm just a little bit lost.

Sorry.

@1:00:20 - Mike C

Yeah, I mean, it's easier just to think of the crud ones, and in doing that, you can see that if you have.

@1:00:30 - estevenson

give an example of, like, a crud one, is that, like, would create, be, yeah, that someone renews their membership, or.

@1:00:37 - Mike C

That would be, that renew would probably be a separate one, because it would be, I mean, it would be based on the type of membership it is.

I don't know, would, you know, some memberships don't have renewal. So, I think a lot of that is going to factor.

The idea is I'm just abstracting it and saying there's going to be an action. Something will happen to the membership.

It will get created. It will get updated. Not directly, not necessarily only directly, but through other areas, updated as far as dues or a lot of these other ideas that we've talked about.

So that aren't cornerstone to the fact that a membership exists. I mean, what about permissions? What if you have content that, what if you have an administrator, if you have different roles?

Like that membership should be able to connect to a lot of different ideas and concepts. Let me try to throw out a sort of more concrete example.

@1:01:43 - JD Leonard (modernbizconsulting.com)

Are you saying that you want to be able to track, for example, that user A updated person B's membership with organization?

And do you also want more information associated with that? Or is that enough information or too much information? Is that an example of a history entry?

Yeah, just something happened.

@1:02:17 - Mike C

Yeah, that's all it needs. Action, the date, who did it, what it was done to. Is it structured data or is it more freeform, like a comment that could describe it?

You could have an action and a note or a message, but yeah, it would be real lean. You know, it's like Watchdog.

It's a Watchdog log.

@1:02:38 - JD Leonard (modernbizconsulting.com)

So this reminds me of, I it's the message. Is it message? Not message. That's the wrong one. Oh, no, that's the right one.

Is it? I'm getting all turned about. But this was, oh, this is modern Drupal. Uh. Here, right? All right, well, that's in Spanish, but, right?

Admin, you know, thumbed up a response, and it has some sort of, in this case, it has an excerpt of something, right?

But it could just have some additional information, right?

@1:03:23 - Mike C

It's an activity log on the membership. Yeah, exactly. Like Watchdog. But it would be specifically for us in a table that tracks and allows us to add subscribers to it, to expand.

I mean, well, no, no, no.

@1:03:44 - JD Leonard (modernbizconsulting.com)

Because I think that would just be message notify or message subscribe, right?

@1:03:55 - Mike C

I mean, this seems like someone would subscribe to the message. This is merely admin of, you know, we're structuring these entities and tracking their activity because that's how we're going to leverage other, you know, we're abstracting it and we're tracking each of the actions that we have.

It's getting logged in our system.

@1:04:27 - JD Leonard (modernbizconsulting.com)

So would the, let me think about this, conceptually for a given action that takes place, there may or may not be a user ID with a logged in user that is associated as like an actor, right?

There may or may not be a contact ID that's sort of associated as the actor.

@1:04:58 - Mike C

Well, chances are if you're having some. Somebody that doesn't have access to anything, they're not doing anything to it.

@1:05:05 - JD Leonard (modernbizconsulting.com)

But what I mean is if a contact renews their membership, even if it's in a third-party system.

@1:05:13 - Mike C

Someone has to log in. No, it could be sourced from an external system.

@1:05:19 - JD Leonard (modernbizconsulting.com)

You've got an external billing system. Well, it would run through a script.

@1:05:23 - Mike C

Yeah, but that would still be done by an admin in the sense that it's either done in code or someone else is logging in and processing something.

So you would basically process the access permissions through someone else. You would authenticate it through something else, but it would still go through that same process.

@1:05:49 - JD Leonard (modernbizconsulting.com)

Yeah, I'm not thinking about the authentication or authorization here, but just the fact that something happened to the membership and we...

No, because we trust the third-party system that it was a given contact that took the action. So is that something we want to track as part of this activity?

@1:06:09 - Mike C

Yeah, anything that happens to the membership entity. It would show up in the history. So you would look at, you know, if you ever looked at the membership entity, it would show you the history of the membership.

@1:06:21 - JD Leonard (modernbizconsulting.com)

And so if...

@1:06:24 - Mike C

Just like that screen you just showed, yeah.

@1:06:28 - JD Leonard (modernbizconsulting.com)

If an organization, ABC Inc., right, joins the Chamber of Commerce and they've got, you know, 5,000 employees and we decide that the appropriate representation for that membership type is to create a member entity for all 5,000 employees, do we generate an activity entry or 5,000 activity entries in our activity about the membership saying that we created these members associated with this membership?

@1:06:58 - Mike C

Yeah, you're creating... You're creating more than 5,000 entities when you create those contacts. So yeah, it's just another entity.

@1:07:06 - JD Leonard (modernbizconsulting.com)

But I'm just saying it's one membership, right? Yeah, that's...

@1:07:13 - Mike C

Brainstorming, do I need 5,000 long entries? It's going to depend on the membership type, though, because that type has to define it as a membership that covers more than one person.

Correct. So the type is going to have... that scenario. Yeah, it'll track things differently depending on the type. So a membership is going to be affected based on its type, and the history is going to record that depending on the type.

So if everything is done at... Yeah, I just... I don't understand the shared membership piece as much. But the idea is that whatever it is...

Because it's going to track its history, unique to itself, based on that type.

@1:08:06 - JD Leonard (modernbizconsulting.com)

Maybe another example of a membership, right? You could have a family membership, right?

@1:08:12 - Mike C

That covers all members of it.

@1:08:15 - JD Leonard (modernbizconsulting.com)

Yeah, yeah, yeah. But maybe just a little more concrete. But you said you didn't understand that membership versus member, or why we would track that separately?

Well, yeah.

@1:08:27 - Mike C

mean, each use case, my use case is not going to be the same as everybody. So you don't want to limit that.

But the idea is that there will be a use case, and it will have logic, and it will do things, and just track that history.

So that we can then use that consistently across all memberships, regardless of the type. But the type's going to dictate what it actually does.

@1:08:50 - JD Leonard (modernbizconsulting.com)

Is there anything else in the system that you feel warrants an analogous history? You'reKEAWRIEFIEFIEFIEFIEFIEFIEFIEFIEFIEFIEFIEFIEFIEFIEFIEFIEFIEFIEFIEFIEFIEFIEFIEFIEFIEFIEFIEFIEFIEFIEFIEFIEFIEFIEFIEFIEFIEFIEFIEFIEFIEFIEFIEFIEFIEFIEFIEFIEFIEFIEFIEFIEFIEFIEFIEFIEFIEFIEFIEFIEFIEFIEFIEFIEFIEFIEFIEFIEFIEFIEFIEFIEFIEFIEFIEFIEFIEFIEFIEFIEFIEFIEFIEFIEFIEFIEFIEFIEFIEFIEFIEFIEFIEFIEFIEFIEFIEFIEFIEFIEFIEFIEFIEFIEFIEFIEFIE Like, also on a contact in the CRM?

Anything that happens involving a contact?

@1:09:07 - Mike C

I think you've pointed out that revision tracks changes to the entities. It's the entity that has relationships outside of it that affect it that don't change the entity itself.

@1:09:19 - JD Leonard (modernbizconsulting.com)

Oh, so you're focused on things external, in this case, to the membership, but are relevant to the membership?

@1:09:28 - Mike C

You just brought up, you wanted to relate it to something else. I'm merely saying membership seems to apply itself well to tracking a history separate from revision, whereas, like, member probably doesn't.

Nothing's really going to affect the member from outside. It's just going to be the member data. It's a place, it's a repository for information, whereas membership is holding a status, it's holding, it could hold permissions, it could hold costs and dues, it could hold a lot of data that isn't stored.

It's more of a hub, and I'd like to track the history of that hub and all the things that happened to it.

Whereas a member, it's just data for the member. You know, like a dues, a dues log, it's just dues.

It's just, that's the, you paid it. Yep, there it is. You didn't pay it. Whatever. A membership type is the controlling piece to the membership.

It kind of filters through it.

@1:10:25 - JD Leonard (modernbizconsulting.com)

So the dues log concept is an example in your mind of one thing that you would want to track about a membership.

@1:10:35 - Mike C

No, dues is a feature. You now can collect dues. You can track the collection of dues. You're not actually doing it.

It's not part of commerce. You're recording the tracking of dues. That's a plug-in to the membership. Now you're giving membership an additional piece.

You're allowing to collect dues. If you want to do other things to the membership, that would be a plug-in.

You don't necessarily need to define it in the membership. Membership is just tracking that connection, you know, and some dates, you know, connecting a type to it.

You know, we've done stuff like this where we end up with like 50 dates and they like it that way, whereas you could abstract it and just have, you know, you could just relate dates to something and have them process it.

But this is still a good way to think it through how you implement those dates.

@1:11:30 - JD Leonard (modernbizconsulting.com)

So a membership activity, you know, log entry, right? Has a timestamp, it has a, some sort of label.

@1:11:45 - Mike C

I mean, Watchdog log is a great example to start from. Can I, can I quickly pull up, let's see, log, slack, let's see, remember history.

Uh, I don't have, let's see, entity, oh, just, oh, whoops, those are reports. Yeah. Uh, date, user, target, role, yeah, this is, this is tracking something more specific.

Um, what's the other project? Yeah. Uh. Yeah. Uh. Fathom, Fathom, Fathom, Fathom, Fathom, Fathom.

@1:13:41 - JD Leonard (modernbizconsulting.com)

All right, so watchdog entries, at least what's exposed in the UI, you've got a type, a timestamp, a message, a user.

What I'm what I'm kind of thinking of is I think there's a. I think there's a potential value in having this sort of thing also for contacts in the systems, maybe potentially for relationships in the system.

Yeah, yeah, right.

@1:14:53 - Mike C

I'm working on a list. Let's see, let's see, let's see. All right, so, what can I, I'm just going to paste it in our platform slack.

All right, so like you create an activity log, which can track an operation, track who did it, describe it.

We wanted a little icon to display, which was generated, which was cute. You would then have the entity that you're referencing, the name of it, label, and the type of entity it was, and then when it was changed.

Let's Or created. I don't think we ever got to changed and created. That was just default.

@1:16:06 - JD Leonard (modernbizconsulting.com)

Well, that's just about the log entry, right? Yeah.

@1:16:09 - Mike C

So you really don't need changed because it's never going to get changed. Oh, I see.

@1:16:14 - JD Leonard (modernbizconsulting.com)

The date it was created.

@1:16:16 - Mike C

I'm actually just going to take that out because it doesn't make sense. Because you only create these if you ever, like, they're never anything that's ever going to be edited.

Which was a problem when I built it because they didn't want an interface for that. But I wanted to be able to see it.

@1:16:36 - JD Leonard (modernbizconsulting.com)

Is the... Is it... I guess... don't know. Well, I was thinking, potentially, is there a need for a second timestamp?

One that reflects when something actually happened and one that reflects when the log entry was created reflecting that that thing happened?

Because you could have an external system that...

@1:17:00 - Mike C

It would be, well, if you're tracking revisions of, well, yeah, you're tracking.

@1:17:08 - JD Leonard (modernbizconsulting.com)

It's not just about a change to the fields, to the properties tracked on the membership, right?

@1:17:15 - Mike C

Once you start adding data of the changed event into the activity log, that's a rabbit hole. It's much better done in the message or the description.

Whatever you're doing, put it in the description. Any data goes in the description. Once you start customizing these four specific use cases, it becomes, it opens itself.

It's a rabbit hole. You don't want to necessarily add data to this specific for one case. That's what the description's for.

It's a generic thing. That's where the event comes in. If we find that we want to do other stuff that this isn't going to do, because it's just tracking.

If we want other reports, if we want other things, we're going to write a plugin that does it, that ties into these events with subscribers, that lets us do that, and then displays it within our dashboards and whatnot as part of the plugin.

@1:18:14 - JD Leonard (modernbizconsulting.com)

Is the operation limited to CRUD, or are there other types of operations?

@1:18:20 - Mike C

By default, it's going to be CRUD, because we have an entity, we're going to edit the entity, we're going to have, it's going to run through the membership type.

Type, that'll be like our first event subscriber, will be our own, like, so the base unit's just going to run CRUD on the member, on the entity.

Outside of that, we're going to utilize our own event structure and our subscribers, so that membership type is going to process an event subscriber.

Supposedly, at the top of my head, that's kind of an example of what I would think.

@1:18:49 - JD Leonard (modernbizconsulting.com)

Yeah, I see what saying.

@1:18:50 - Mike C

So whatever we're doing outside of the basic entity stuff would be tied into the event subscriber. And process through that.

And if we name this as ActivityLog, we can use it for other entities, like users, like you were saying.

And then membership activity is merely what is getting processed. We build the plug that we're going to build, you know, make sure the, when the membership type gets processed, it does what it needs to do.

Those activities get logged.

@1:19:35 - JD Leonard (modernbizconsulting.com)

So the, yeah, so this seems to me very analogous to the message stack in Drupal, right? Like there's, there's a message which refers, which is an entity representing an ActivityLog, right?

It doesn't have any exempt subscribers though.

@1:19:53 - Mike C

You can't tie into it.

@1:19:57 - JD Leonard (modernbizconsulting.com)

And what we're right, what we would.

@1:20:00 - Mike C

And incorporate, well, we can still write the event subscribers, the events separate from the activity log. It's just they're hand in hand.

Every time you're doing something, you'll want to track it being done. So if it were like just your generic, yeah.

And perhaps that, perhaps, what if I think about it? What if I present it this way? What if our activities are the plugins to the activity log module?

It just tracks activity log. And we're just writing event subscribers that track stuff we want, when we want it.

And that way we I really think you're just reinventing the message stack.

@1:21:05 - JD Leonard (modernbizconsulting.com)

I think Drupal already has this in Contrib. It's also fieldable. can have different message types that are fieldable that help influence what makes it into the message in the activity log.

@1:21:25 - Mike C

It's not for users to see. It's meant to track the activities behind the scenes of what's happening. You're saying nobody looks at it?

@1:21:41 - JD Leonard (modernbizconsulting.com)

Not really.

@1:21:42 - Mike C

Not users. None of the members will.

@1:21:44 - JD Leonard (modernbizconsulting.com)

Not the members, but an organizer of the organization? Not necessarily.

@1:21:54 - Mike C

Not necessarily. I mean, those would be the reports we would generate for them when we get the dashboard pieces.

But this activity log. would be where we would go to access that data. We're previewing a system that does allow us to build these reports, and we're building it so that we can track exactly what it is we want to track, and it's in a format that we're going to use in this manner, and other things will, could, you know, write to it and utilize it as well.

And that's why I'm like, why is it, it's not really member specific, it's just events, and if we're writing events, we can log to this as we call our events.

As we make our code as object-oriented as possible, we build these events to it so that we can add to it and expand.

@1:22:48 - estevenson

I know one point where I'm getting confused is that even if we were to implement this, we'd still need to come up with a standard way of using it for standard things, so kind of...

Yes, that theoretically this could contain anything, but we still need sort of like a way to track, yeah, that a person sort of joined or that they're expiring or that, you know, kind of, they created this membership.

That, you know, kind of, it could totally kind of track other things and sort of built it and said that flexibility, but we still need to figure out how to implement, like, the events that are specific there just so that, yeah, we have behavior that can ease off of it.

@1:23:28 - Mike C

So how would we do that? They would be through the other features. This is merely for devs to be like, oh, my gosh, look at our wonderful system and how well it runs and how everything is so well organized and, oh, my gosh, let's build a new piece that adds to this and it just shows up in the log.

Oh, that's so cool. Like, that's going to be nice to see everything pop up in the log. So, oh, look, the commerce plugin's working.

Look at that. It's in the log. This is great. We just created it. It did the connections and boom.

reconnection. It's It's showing up in our log. The commerce piece still needs to do its stuff. If we have a dues plugin, it's still going to do its things.

If the dues is going to expire and change the membership, that's part of the plugin. It's still doing that.

But we're going to log a history that says dues expired the membership. Boom.

@1:24:18 - estevenson

I know that, for example, in order for me to have a membership kind of expired date, I need to be able to sort of know that membership was created.

So there still have to be a standardized.

@1:24:32 - Mike C

So yeah, even if we were to system, this is where I'm getting a bit lost.

@1:24:36 - estevenson

You still have to kind of design the specific things for our use case. Because you'd need behavior that keys off that.

So how would that look inside your idea? Where I'm getting a little bit lost. I'm not.

@1:24:50 - Mike C

I'm merely changing. I'm trying to talk about tracking the history of something as opposed to the dues of like the.

Choose a piece, a plugin to the membership. Membership's the hub. And as long as we're going to be adding all these pieces, it would be super nice as a dev to see a history of everything that's happening.

SCREEN SHARING: Jd started screen sharing - WATCH

@1:25:16 - estevenson

It doesn't do anything.

@1:25:18 - Mike C

You're not going to use the history in any of your code. You're not going to go and say, well, when did this, you're not going to use it in your code.

The code is still going to use the created date off the membership. It's still going to use the expired date.

It's going to use the start date on the membership. But when it triggers, when Cron goes and triggers it and says, boom, you're now active, you've just changed your state of membership, that's going to get logged in the history.

When it gets created, it's going to check, like, you just created a membership. It's now active. You just created a membership.

It'll be active in the future. Like, those things are the history. They don't, they're not going to go back.

So the activity log.

@1:26:00 - JD Leonard (modernbizconsulting.com)

Uh, is used for reporting purposes, debugging, reporting, all kinds of, yeah, basic, and, and, and I think there are, there is some subset of the information in that log that may be interesting to expose to people with the right access permissions, right?

@1:26:25 - Mike C

Right.

@1:26:25 - JD Leonard (modernbizconsulting.com)

So right now I'm showing a screenshot from, uh, my neighborhood associations, accounting software, right. That shows the activity associated with my, with me as a person, right.

In the system. And so it's got different types of activity, right. That occur. And it has some structured data around that.

And I know Mike, you're saying that we don't want to deal with structured data here, but I think there's, there might be another.

You can tie.

@1:26:56 - Mike C

So once you've recorded that activity, you know, you. So you're going to have an entity relationship. You're going to have information that you can then go and get more data to show.

Yeah.

@1:27:15 - JD Leonard (modernbizconsulting.com)

So, for example, right, for a member, right, we might want to expose to them when they're logged in information about how their membership has changed over time.

Right. Here's your membership history. Right. That's the original kind of name for what you were describing. Right. And so we could expose a subset of the activity log entries related to their membership to them because it's relevant to them.

@1:27:43 - Mike C

Correct. Yeah. And that would be very, yeah, that would be the idea for the member to see that stuff.

But there are also, you know, there's a lot of potential. You're just tracking. You're tracking. tracking. Your actions that you're writing and you're seeing them in a nice little, I find that to be very, very helpful to communicate amongst people the status of things.

So what's happening? Look at the history for this and this is what's getting recorded. Yeah, but I did this and it didn't happen.

Or look at the message. It's very helpful. And not have to go through revisions and watchdog logs and all of those different places to store stuff.

This will be kind of track our memberships.

SCREEN SHARING: Jd started screen sharing - WATCH

@1:28:35 - JD Leonard (modernbizconsulting.com)

And so going back to here, the concept of the dues log. Now there's the more structured version of that data, but then there's just being able to expose that there was some dues related activity about the membership, which could be a member.

Membership activity log entry. Yeah, exactly.

@1:29:05 - Mike C

It would, yeah, it would tie into.

@1:29:09 - JD Leonard (modernbizconsulting.com)

And you could have a different plugin that generates that from Drupal Commerce or from an external billing system or from a module that just lets the organizer add manual, you know, and manual information in, right, to, to sort of keep track of some of that stuff, right?

Yeah.

@1:29:35 - Mike C

So you would, there's two events that we need. We need one that allows the plugin to define the log entry, you know, in a way, it's kind of like the membership type.

You're defining a type of membership. You're going to define a type of log entry and then the actual log entry.

Those are the two pieces in the activity log that you need in the plugins to make it. Tie into it so that the activity log knows, oh, I got to log this, and then it sends it off, and it logs it.

@1:30:15 - JD Leonard (modernbizconsulting.com)

So, getting a little more concrete here, timestamp, the membership that it's about, some sort of type, right, which might refer to the plugin or something, right?

@1:30:30 - Mike C

Yeah, you can go to where it's from, who's controlling this. I'm going to skip these for the moment.

@1:30:35 - JD Leonard (modernbizconsulting.com)

There's a message, right, which is freeform generated by the plugin. And then I had acting contact and acting user here.

So, in some cases, somebody is logged in, right? So, there's a, when performing an action, so there's an acting user.

They might or may not be in the plugin. Context of performing an action as a contact, right? So if they're logged in as a user who is associated with a contact, right, they are the person, they are the contact that is logged in.

@1:31:16 - Mike C

Well, there's the user is actually doing it in the system, and then there's the contact associated to the membership that we have.

Well, that would be, you could get to that via the membership, right?

@1:31:31 - JD Leonard (modernbizconsulting.com)

Or what I'm getting at is that the acting contact could be not the same contact associated with the membership.

Not quite.

@1:31:42 - Mike C

That would be the user. That's why I'm not clear about how you give permissions to people that log in as one person.

@1:31:50 - JD Leonard (modernbizconsulting.com)

So CRM has basically a way of relating a user to... A contact in the system. And so the user will inherit permissions based on that contact.

A lot of this is still to be implemented, right? But conceptually, that's the idea. And you could have a user log in who has the ability to edit other contacts, for example, because the contact that they represent has relationships with those contacts.

@1:32:31 - Mike C

Okay. I'm just not sure how the user assumes a contact identity.

@1:32:42 - JD Leonard (modernbizconsulting.com)

You mean, like, technically, like, or, or conceptually? Conceptually is fine.

@1:32:49 - Mike C

Yeah.

@1:32:50 - JD Leonard (modernbizconsulting.com)

So a user who logs in can be associated with a contact that represents them. And because basically everything we're...

So tracking in this system, right, has it with contacts? I don't know if that explained it or not. Well, I mean, permissions, right?

@1:33:12 - Mike C

To do something on the site, you need to evaluate your permissions. And a general anonymous person coming onto the site is going to have the same permissions as anyone else.

You don't have a way of authenticating that person. So the user system allows them to log in and identify roles and permissions.

You can then have ways to assign a user to have permissions to access a group of entities, those entity contacts, and you could edit them.

But you don't know, like, if those contacts are, in essence, people, and those people are able to access and edit each of the contacts, you need to assign permission to that person, and they need to log in.

And they need to use that one login to do it.

@1:34:04 - JD Leonard (modernbizconsulting.com)

Yeah, so I believe there would be basically access control plugins that convey access to a user based upon the contact that is them, right, that represents them in the system, and that contacts relationships, memberships, etc., right?

So we don't actually manage the permissions directly on the user entity, right? It's sort of inherited by virtue of being associated with the contact, just as it relates to CRM, the CRM ecosystem and the data being tracked there.

@1:34:46 - Mike C

Right, well, cart before the horse, right? Like, how do you know what contact you are? Are you making the contact the login system and do you have passwords and stuff for the contacts?

@1:34:57 - JD Leonard (modernbizconsulting.com)

So, one scenario is A user creates their account, they're joining, and they're creating their own contact entity under the hood in the process, right, that represents them, right?

So they fill out their profile information, and, okay, they need login credentials associated with the user, and there's a reference to their contact, which is where their other information gets stored, right, their name and their address and whatever.

So that's one scenario. Then that link is already established, right, when they create it. Another scenario is you have an organizer on this site creating contacts, right, and there would be a way for them to link it to a user.

So they could create a user, link it to a contact, and invite that user to come login, as one example.

And then, of course, there are going to be contacts for which there is no associated user in the system.

And you could also have users for which there is no contact.

@1:36:02 - Mike C

Wait, you didn't explain how a contact without a user accesses the system?

@1:36:08 - estevenson

I know one scenario I can imagine is that the organization I'm with represents people who kind of like are unstably housed.

But you're kind of they do have sort of stuff that unlock kind of like if you show up at the sort of like clubhouse often enough in order like you'll kind of job opportunities and stuff.

So you could have someone who just sort of like shows up X, Y, Z, you know, kind of. And I'm not worrying about how this would show up inside the system, but they're able to just sort of like effectively upgrade their sort of membership without ever directly having access that it's able to just kind of.

Yes, you've shown up long enough that now kind of like this person is eligible for X, Y, Z, and you could have kind of something where one contact, you know, kind of like.

Yeah, one user sort of initially admitted this person. That user kind of leaves the organization. And then kind of the system, yeah, like there's a place where you can kind of like tap cards.

So that goes inside an Excel sheet to track the person kind of showed up this day, showed up this day, showed up this day.

And yes, sort of like without the person ever logging into the system, you could have changes to their membership.

So, yeah, and you could have like one person creates them, and then one person kind of is handling the event later on where they're kind of upgraded.

So, yeah, how that would get represented would be kind of its own implementation detail. But my understanding is the system is supposed to be able to kind of track contacts inside that way where they're not users.

@1:37:49 - JD Leonard (modernbizconsulting.com)

That's correct. So you can have an external system, right, that in this case is your badge tapping system, right, that, or your Excel sheet, right, that

That, you know, add some activity related to the contact. Now, don't know that that activity would necessarily be related to a membership.

Maybe it would be if the card represents the membership that they have or something like that. I don't know.

The library card, right, represents your membership to a library. Mm-hmm. But I think it's an interesting question as well about, like, well, where does that, what does the, what is the activity on?

Is it an activity on the membership?

@1:38:29 - estevenson

Is it activity on the contact? Mm-hmm.

@1:38:36 - JD Leonard (modernbizconsulting.com)

Hmm. But, Mike, back to your previous question about, well, okay, so I was asking about what we track on this activity, right?

So sometimes there is a user who is logged in, who is performing the activity, so clearly, right, we can track that, right?

Mm-hmm. Sometimes they are. They're acting as a contact, right? Because they are logged in and they are associated with the contact that is them.

So it is useful in our system to track that association. Wait, so you're going to have users that don't have contacts?

You could imagine a more administrative user, right?

@1:39:21 - Mike C

Might not be a contact, but could still perform actions. Okay.

@1:39:30 - JD Leonard (modernbizconsulting.com)

Um, you know, an administrator of, uh, of a group who is not a member of the group or who's acting in an administrative capacity rather than in their capacity as a member.

@1:39:48 - Mike C

Right. Well, that gets to roles.

@1:39:52 - JD Leonard (modernbizconsulting.com)

Yep. Um, okay.

@1:39:57 - Mike C

Yeah. And yeah, you.

@1:40:00 - estevenson

They're acting as a contact, right? Because they are logged in and they are associated with the contact that is them.

So it is useful in our system to track that association. Wait, so you're going to have users that don't have contacts?

@1:40:17 - JD Leonard (modernbizconsulting.com)

You could imagine a more administrative user, right? Might not be a contact, but could still perform actions.

@1:40:28 - estevenson

Okay. Um, you know, an administrator of, uh, of a group who is not a member of the group or who's acting in an administrative capacity rather than in their capacity as a member.

Right. Well, that gets to roles. Yep. Um, okay. Yeah. And yeah, you. Could have kind of things like, yeah, a preschool where, you know, kind of a contact is, you know, effectively a five-year-old kid who then gets sort of paid for, you know, kind of by their parents.

@1:41:11 - JD Leonard (modernbizconsulting.com)

So that contact literally couldn't interact with the site. Yep. But is a, let's see. And yes, you might want to be able to track the activity in terms of events that kind of, I am the mom, I registered inside the system, I have two kids.

Kid one went to event A, and kid two went to event B.

@1:41:40 - estevenson

And like, later on, I want to look at kind of the history of both of them. So, yes, you could have a contact page for both of them, but there's only really one user involved.

Which, you know, kind of logically inside the system, as I understand, it would be associated with the household. But yeah, there definitely are scenarios where, um...

@1:42:00 - JD Leonard (modernbizconsulting.com)

So you could have a contact without a user or a user without a contact. So a membership activity of a child, I'm trying to think of an example of this where the child does something, right, but the activity is tracked by their parent.

But is the acting contact the child or the parent? Yeah, so kind of you could have like a geocaching sort of group where the kid goes out and does the scavenging, is able to sort of find that, and then the parent logs it.

Yeah, no, I mean, I've lost the thread so much.

@1:42:59 - estevenson

Yeah, we... Yeah, We've definitely gone down a bit of a rabbit hole. And I think one of the challenges as well, right, is we're kind of thinking of different scenarios where we would have activity to track, but it's not necessarily activity about a membership.

It's just activity, in some cases, about contacts, right? And so I think one of the challenges in, you know, building a system to support this is what you got at earlier.

@1:43:34 - JD Leonard (modernbizconsulting.com)

It's like, what are the best practices? What are the, you know, how should the different events be structured, right?

And the different activities. And I understand it's kind of all deferred, you know, delegated to the plugins, right? Like, them, let them decide to a certain extent.

But yeah, kind of. For membership platform, we would effectively be writing our own plugins to the system, and then we'd have to figure out, well, what should those look like for the behavior we want?

And yeah, kind of, there are predictable events that you'd have with any type of membership program, like renewal. So logically, there'd have to be a best practice for using this system.

Yep. mean, this would also be useful for tracking things like upgrading a membership, right?

@1:44:37 - estevenson

Downgraded.

@1:44:38 - JD Leonard (modernbizconsulting.com)

If a membership gets upgraded or downgraded or whatever, right? Um, per, per Steve's vision of this, that would result in a new membership entity.

You would not change the membership type of the existing membership entity, right? You would not Compain the record that, you know, you might bring the expiration date forward, right, for the old membership, and then you create a new membership of an upgraded type with a start date of today or whatever's appropriate.

@1:45:16 - Mike C

But then in the membership activity log on the old membership, right, it could say, hey, upgraded to, you know, this other membership type, and it could have a reference to the new membership.

So you can kind of navigate there, right, somehow. And on the new membership, it would have an activity log entry saying, hey, upgraded from this other membership, right?

So you kind of build some less structured information about what happened and why that can then be exposed, you know, in looking at the history of somebody's membership to understand what happened and who was involved, et cetera, et cetera.

@1:46:01 - JD Leonard (modernbizconsulting.com)

I think I'm on board, Mike. Thanks for bearing with me. I'm not sure that it would be the first aspect of the system that probably would be implemented, but I see the power of it.

@1:46:17 - Mike C

Yeah. I mean, yeah, the way I look at it is everything's going to kind of leverage the system the same way as this.

@1:46:25 - JD Leonard (modernbizconsulting.com)

This is just going to simply track a log entry whenever it's doing anything, whereas everything else is going to tie into it when it needs to, because this is going to trigger some things and vice versa.

Other things will trigger this. We just want to make sure that we're able to see it quickly rather than have to go through too much to see what's broken and what's not.

@1:46:55 - estevenson

Yeah. All right. Cool. Do y have any other thoughts on the pieces of information we track here? We haven't really resolved some of what actually belongs on membership.

Yeah. But again, I think where my head's at is just basic information. Other stuff's going to tie into it elsewhere.

This is basically what you're going to need to track this.

@1:47:32 - JD Leonard (modernbizconsulting.com)

So, I mean, membership represents the current membership, right? Or it may represent a past membership if you're not a current member.

But I think the real tricky part is what about that future membership state? Yeah, I know kind of like I'm just trying to imagine the scenario where kind of I am on the front end of this.

If click kind of like a button saying, you know, kind of like upgrade sort of like this, you know, kind of user's thing, then what happens on the back end?

Because like, yes, like for the front end of this, that's logically an activity that we would give them.

@1:48:18 - estevenson

And, you know, kind of, yes, I mean, would this have its own sort of plugin for kind of membership sort of actions?

Because, yeah, as part of the front end, we want to provide kind of people the ability to use this log however we're using it.

So the, you gave the example of upgrading a membership. So that one I feel like is maybe more straightforward than dealing with some of the future stuff, right?

But if you've got a current membership and you're going to upgrade it, then you would set the expiration date for this membership to now.

You would. You You know, that would change the status maybe or something, right, of the membership. You would create a new membership of an upgraded type with a start date of now.

And Bob's your uncle, right? Oh, and then, you know, kind of, if I wanted to see a history of, for me, that's one sort of continuous sort of membership, you know, kind of like what happens on the back end in order to sort of show that, or do we even worry about that?

@1:49:32 - JD Leonard (modernbizconsulting.com)

Can you describe the use case again?

@1:49:34 - estevenson

Okay, so I am, you know, kind of, this is me imagining a front end, so kind of like out of scope is perfectly valid.

But yes, so I have gone, I have upgraded my membership. Then kind of like two months later, for some reason, I need to remember kind of like when I did that, and when I started the original membership, because from the user's perspective, this is one thing.

And I want to see an activity log. But, you know, kind of you can always just sort of stitch it together.

But, you know, kind of like how does the front end implement that?

@1:50:07 - JD Leonard (modernbizconsulting.com)

Like, does it do kind of like sort of a daisy chain back? Because, I mean, maybe I've upgraded multiple times.

Or do we have something that kind of indicates a continuous relationship? I don't know. Yeah, kind of. I might be overthinking it.

Sorry. I think you're just talking about a view that shows membership activity of a certain type for that membership.

@1:50:33 - estevenson

Sorry, not for that membership, for all of the memberships associated with the contact. But let's say I have two different memberships.

And I kind of like upgrade sort of one of them so that kind of like it gets sort of done.

And then I want to see kind of like a history of this relationship and this relationship from my perspective.

So I would not want to have kind of So you could definitely have a view that lists your memberships, right?

One of them is probably active, maybe you've got a downgraded one that is no longer active, right?

@1:51:25 - JD Leonard (modernbizconsulting.com)

And you could further expose the activity related to the, you know, each of those memberships in the context of that membership.

Because you were worried about keeping that information kind of separate about the different memberships or? Well, I'm more thinking I have two active memberships.

Kind of like I change one of them. So that you're kind of now within the system, sort of like that, when that was active is deactivated, and now there's another new active one, then I want to look at the history of both sort of things.

Do I?

@1:52:00 - estevenson

I get kind of a panel where there's three relationships, so there's the one active one, there's the other active one, and then there's the one kind of cancelled one, or, you know, kind of like, or the upgraded one, or do I just sort of like, see the one that was upgraded, so that kind of start, yeah, kind of, would an upgraded sort of like thing inherit the start date of the previous ones in terms, yeah, like I'm...

I could see, I could see there's like, you click on my memberships, and you get to a list of your memberships, and then you could click into one of those and see the activity associated with that membership.

Maybe, you know, separately, if it makes sense, you could have a, you know, somewhere where it displays all of the activity related to all of your memberships, right, and each activity, you each row in that table would have context.

About which membership it was related to, right? You could click to and see more information about the membership. I I don't know if we'd expose all of that to a member.

To me, kind of like, does there need to be any connection?

@1:53:11 - JD Leonard (modernbizconsulting.com)

So I've upgraded my membership, where kind of the upgraded membership is somehow linked to the past membership, that you kind of could do that through, yes, you could do that through logs.

Like, do we want to do that through logs? You mean, do we need a more, a stronger connection between the two in the system?

Kind of that, yeah, like in this, to me, kind of the answer could be no. But, yeah. That's where I'm going.

Yeah, no, no, no, no. I just, I just sort of wanted to make sure it floated that, that yes, within the system, if you're upgrading it from the front end perspective, that this is considered a new relationship, and there will be kind of like beyond that.

@1:53:52 - estevenson

A new membership.

@1:53:54 - JD Leonard (modernbizconsulting.com)

Yeah, and beyond kind of a log, which is sort of available, that from a front end perspective. We would present them as three different relationships inside this scenario, even though one was upgraded from kind of a past one.

Yeah, I think one of the things that I have yet to identify like a real use case for is, like, do I really need to understand anything about the contiguousness of a given membership, right?

And I feel like if it's important to an organization, like, let's say American Express, right, to keep track of when somebody, like, first joined up, that sounds like something they could just add a field on the contact for and be like, that was their, you know, original joint answer.

@1:54:47 - estevenson

Yeah. Cool.

@1:54:53 - JD Leonard (modernbizconsulting.com)

So then I, I think this dues log concept gets folded into the membership activity. As like the first piece, right?

Now, maybe there's a more advanced system that could be created that separately is sort of tracking Gu's information with an eye towards, you know, financial reporting, as opposed to just looking back at activity.

But I think the primary reason for having this was to be able to give a sort of at-a-glance look for an organizer, be like, hey, like, when did they pay?

Right? Kind of reconciling what all is going on. I think the activity log covers it. And yes, kind of like stuff like start date, end date would be like put inside the message sort of field.

Yeah. Okay. Yeah. Is that sort of going to be like a JSON where you just sort of put whatever makes sense?

Makes sense. So I referenced the message stack earlier. It's been years since I've used it, but the way that they structured this, which I thought was very elegant, is you define different message types, which basically just defines sort of how, what stuff appears on a message, on an individual message.

So in this case, it looks like they've got a single message type that's sort of relevant here, right, that has a message type is fieldable.

So you track the information you want to track for each type of message. So if you want to track a start date and an end date, right, because it's relevant to the message, that gets tracked.

But then you can use tokens, for example, to extract. use for example, to The little bits and pieces from those fields on the message of a given type to form the message, right, that gets output.

Okay.

@1:57:12 - estevenson

So further, you know, evaluation necessary as far as whether that's the most appropriate system or not. But that also affords for things like a little icon if you want an icon and how does that get generated and stuff like that.

@1:57:29 - JD Leonard (modernbizconsulting.com)

But then that basically is a part of the pipeline for creating the message, right?

@1:57:34 - estevenson

Once you have, once that message entity gets created, you lose the structured part of that data, right? Like it's, you'll have, maybe you'll have a link embedded as part of the message.

@1:57:49 - JD Leonard (modernbizconsulting.com)

And maybe overall, like here it looks like they've got some tags and other, you know, stuff like that. And a reference to another entity.

So like there's some way to retain some of that structure, but it's...

@1:57:59 - estevenson

Yeah. I don't know. It's pretty involved to define the information architecture for that stuff.

@1:58:08 - JD Leonard (modernbizconsulting.com)

I don't know that answered your question. Yeah, no, no. Kind of like just conceptually message is a stuff field as opposed to a logging field.

It's just sort of like how I'm mentally translating that, and I am happy with that approach. Oh, this describes the stack, but But yeah, so no, it pretty much has a field for, yeah.

Right, so you, you have message types, so you can have, here they have an entity reference to the node, right?

Okay, so you might So pretty much you could have an entity associated inside the message field, and then it would contain a link to that entity.

Correct, but when you're, it uses that reference to generate the mess, well, no, I guess the message does retain some of the structured data.

Honestly, I don't remember. It's been so long since I've used it. No, no, no. It's not super important to nail it down right now.

Right. All right. Oh, let's see. Yeah, we don't need to do that. Okay. So then back to the membership itself, because we still haven't quite figured this out.

I think join date... We probably don't need, like that was the kind of member sense for American Express, I think, right?

@2:00:08 - estevenson

So if we primarily rely on an activity log to give us a history of what happened, right?

@2:00:18 - JD Leonard (modernbizconsulting.com)

Then the membership entity represents generally the current membership, but it might be past membership. And then we need to figure out what happens with future memberships.

And also, we haven't exactly discussed what happens with renewing elapsed membership. Why don't we take renewing elapsed membership to start?

So I've got a 2024 membership. It's 2025, so.

@2:01:02 - estevenson

Very good.

@2:01:03 - JD Leonard (modernbizconsulting.com)

Thanks, Mike. Good discussion.

@2:01:09 - estevenson

Yeah, so no, so I have a lapsed membership, and then I am renewing. Right. But it's renewing for a future date.

Well, let's start with just renewing straight up. Okay. Well, okay, so there are two different scenarios there. One is I've got a 2024 membership.

@2:01:30 - JD Leonard (modernbizconsulting.com)

I'm in the middle of 2025, and I renew my 2025 membership, and it gets backdated to January 1st, 2025.

So we could just extend the expiration date of the membership entity. Right.

@2:01:48 - estevenson

Another is, okay, I'm doing my 2025 membership, but it doesn't backdate it. It's only effective as of today through the rest of 2025.

@2:01:59 - JD Leonard (modernbizconsulting.com)

How do we recommend Present that on the membership. Do we update both the start date and the expiration date?

I think that might be the answer. of, yeah, to me, to sort of, yes, under what conditions do we archive kind of a membership?

@2:02:15 - estevenson

Do we, like, only have one membership for kind of, do we only have one membership record, one active membership record per, no, because, mean, obviously you can have two.

Well, ignoring future, the future stuff, right, we can get away with having, at most, one membership entity for a given membership type and organization.

@2:02:41 - JD Leonard (modernbizconsulting.com)

Yeah. Sorry. Membership type, contact, and organization. Yeah. Would organization double as household? Organization, no. I, membership is always to an organization.

Okay. Yeah. A household has, would have a relate, you could have a relationship between its quote unquote members. Yeah, no, I'm just thinking of that scenario.

So kind of like for the membership record, I'm again, imagining that mom with two kids, um, you know, kind of the contact would be the household.

@2:03:23 - estevenson

Um, and then that household would kind of like, yeah, like have head of household and then two sort of stuff.

And then, yes, I would just sort of like go back through that. So I just sort of like, oh, this membership is to this household.

Then programmatically, I would figure it out from there. Oh, so yeah. So, so what the scenario you just described, right, is the, the contact is the household.

@2:03:48 - JD Leonard (modernbizconsulting.com)

Because the household has relationships to its constituents, member entities can be created for each person in the household. Right?

But another way to represent the membership would be, instead of a household, maybe it's a membership.

@2:04:15 - estevenson

Well, you can imagine that the children could technically span multiple households, right?

@2:04:19 - JD Leonard (modernbizconsulting.com)

No, Kind of like, and then I'm thinking, well, I want to go to this child's page, and I want to see all the stuff that they are kind of a current member for.

Then does it kind of like, I kind of look at all the households that they're associated with, and then for all those households, I check kind of like all the relationships that they're sort of part of, and then I go to kind of like the start date.

Like, that is doable, but it feels like an indirect way to get the information. You're saying, if you're saying if you navigate to the contact record for a child, and they have, they belong to two households.

And each of those households has a membership? Well, kind of. mean, each of those households might have a membership.

Right. So you'd have to go and check.

@2:05:13 - estevenson

And then of the memberships that could belong to each household, they may or may not be current, or they would have different states.

@2:05:22 - JD Leonard (modernbizconsulting.com)

So I don't think you have to actually do a lot of clicking, necessarily, right? So if you navigate to the contact for the child, if they have a membership sourced from both households, then there would be two member entities for the child, one for each membership, right?

@2:05:56 - estevenson

And that can be exposed without you having. To navigate to each membership, right? And presumably you could also have, you know, you could expose information about whether the membership is active.

Does that cover it? Yeah. No, no, no.

@2:06:16 - JD Leonard (modernbizconsulting.com)

I'm just sort of like trying to think of what does the complexity look like? And like, yeah, I would agree all of it sounds manageable.

I think the complexity is that it's hard to create sensible defaults because every organization is going to have unique requirements and interests about what they care about, the information they care about.

And so for a lot of organizations, like, they just kind of have to customize it. But as long as the underlying data is sound and the relationships, I lose the term loosely, right between the data is sound, then that'll all be possible.

And that's all we're really worried about is that... Does this relationship model cover cases? Yes. Okay. For now. Okay, so now I'm just trying to remember what we were thinking of.

@2:07:16 - estevenson

So, okay, we were talking about membership, and we were talking about what do we do to the membership when we renew?

Mm-hmm. And we said, if we're renewing and backdating, we can just extend the expiration date. Yeah. If we are renewing but not backdating, it means there was a gap in our membership.

Mm-hmm. So one thing we could do is update both the start and the expiration date for the membership, and now it represents our current membership.

Or we could create longer represents the past membership.

@2:07:55 - JD Leonard (modernbizconsulting.com)

The revision history could capture that. That and the activity log could capture that in two different ways.

@2:08:06 - estevenson

Right? Yeah. I'm not 100% sure whether we need the revision history on the membership. Yeah. No, like, mean, having an audit log is always nice, but that's already kind of built into kind of sort of entity.

activity log. Yeah. So, yes, no, and, you know, kind of people can build off of that. I know my instinct is that start date should be treated as immutable.

@2:08:40 - JD Leonard (modernbizconsulting.com)

And if start date is changing, then that should be considered a new membership. Just because, yeah. That just. I know what you mean.

That was also my gut reaction. And I'm still trying to reconcile internally. I that's cool. Yeah. Well, yeah, no, just because, I mean, if nothing else, I'd want to call it something else, because, like, I know if I were kind of, like, looking at this and trying to puzzle it out after it's created, and I'm trying to figure out start date, and I'm, like, creating module, I'm absolutely going to make stupid assumptions.

@2:09:21 - estevenson

So, like. So are you proposing, then, that. I mean, like, possibly, like, one, one, I might just have a start date, and then maybe activation date, just so that, just intuitively, that is different, and then activation date can change.

So, well, okay, let's come back to that, but are you proposing that if there is a gap in membership, like, between conceptual memberships, that they should be represented as two different membership entities with, you know, their.

@2:10:00 - JD Leonard (modernbizconsulting.com)

Unique start and expiration dates?

@2:10:02 - estevenson

Yes. You'll kind of... But are you saying if you renew a membership such that there is no gap, that you just extend the expiration date?

@2:10:15 - JD Leonard (modernbizconsulting.com)

That, to me, makes more sense than changing start date. Because, like, you'll kind of, like...

@2:10:23 - estevenson

Yeah, like, when the relationship starts, to me, is immutable inside time.

@2:10:28 - JD Leonard (modernbizconsulting.com)

Um, and, well, like, I mean, it makes sense for expiration date to change, because that is a future thing.

Um, just intuitively, that makes more sense to me.

@2:10:40 - estevenson

Yep. And if we did want to kind of, like, change sort of, like, the start date, my sort of gut reaction is make start date kind of immutable and have, like, activation date.

And activation date can change, but the start date doesn't, because just, it hurts my brain.

@2:10:56 - JD Leonard (modernbizconsulting.com)

The start date is the start. Right. Right. And, you know, kind of like, and if you're doing something that involves sort of like a different start date, then that is, that is a different membership.

And yeah, the only scenario where I can see it.

@2:11:12 - estevenson

Yeah, that if you want to, sorry, you go ahead. Do you feel like, do you feel like the membership entity needs to track when you last renewed?

Um, that would, yes, you know, kind of like, maybe that exists as just sort of like logging, because I mean, that's what we have it in the log.

So my question is, do we, is there a reason we would also need it to be more structured and concrete?

Um, yeah, last renewed would just sort of, hmm, because no, and then comes the sort of thing is last renewed, should that be kind of the start date of the last renewal?

Or should it be the date that you kind of applied to renew it?

@2:11:52 - JD Leonard (modernbizconsulting.com)

Because that's now... Well, take either, take either one. Like, is that, is that worth tracking? Separately from the activity that would also track it?

I think the answer is no. Like, I don't think we need to track that as, like, strongly structured data.

@2:12:10 - estevenson

Mm-hmm.

@2:12:12 - JD Leonard (modernbizconsulting.com)

Yeah, like, yes, inside my mind, I would want expiration date, because I can understand extending it.

@2:12:21 - estevenson

Um, yeah.

@2:12:23 - JD Leonard (modernbizconsulting.com)

And, know, kind of, what are, but yes, if you're changing start date, then, um, kind of, like, why, why would you want to keep that membership?

Like, the one thing I can think of is that you had a history. Um, and you want to sort of, like, have continuous history with this particular entity.

But, um, should we just tell people to leapfrog if you're doing that? And just sort of, like, if the start date is different, then that is a new relationship, or, like, a new membership.

@2:12:49 - estevenson

I, I do like the concept, I think, of membership being contiguous. Like, a membership entity being contiguous. Okay. And the reason that you would have...

@2:13:00 - JD Leonard (modernbizconsulting.com)

So another membership entity or a contact with an organization of the same membership type is because you've had a gap.

That then, I think, solves our challenges with future, well, yeah, with future memberships, right? Because if you have a future membership, a membership that's going to start in the future, well, if it's the same type as your existing one and it would be contiguous, you simply extend the expiration date.

You don't actually need a separate entity to track the future one. But if it starts on a future date and there would be a gap, well, then you simply would have an additional membership entity, right?

Like that, you know, kind of like that, that, that represents the two states and you're kind of allows for kind of lapsed memberships.

Yeah, that to me is a good approach.

@2:14:03 - estevenson

All right, let's just document these examples of membership scenarios, right?

@2:14:15 - JD Leonard (modernbizconsulting.com)

So let's start with I'm not, or let's say I've never been a member.

@2:14:32 - estevenson

I've never been a member, and I joined, right?

@2:14:37 - JD Leonard (modernbizconsulting.com)

So create membership entity with start date and expiration date, right?

@2:14:49 - estevenson

I don't know if this is quite the right thing.

@2:14:51 - JD Leonard (modernbizconsulting.com)

Kind of like you have to deal, I am a member, I've never joined, and it's a lifetime membership, so there might not be an expiration date.

I'm sorry, you're right.

@2:15:00 - estevenson

That is not counted for here. We talk about it here. There needs to be a flag, basically, for is it a lifetime membership.

@2:15:10 - JD Leonard (modernbizconsulting.com)

That would make sense to me. Or just no expiry.

@2:15:30 - estevenson

Has expiration date. Yeah, that works.

@2:15:35 - JD Leonard (modernbizconsulting.com)

That's better than no expiration date. Has expiration date, and then the actual expiration date, if relevant. I've never been a member, and the membership has an expiration date.

Well, get... Yeah, okay. And then there's also kind of an and I join immediately. I don't know if there'd be different behavior if I've never been a member and I join inside the future.

You know what, we can probably simplify and just say, I've never been a member. Well, no, I like what you said, okay.

@2:16:23 - estevenson

Join a meeting.

@2:16:24 - JD Leonard (modernbizconsulting.com)

Yeah, we're really talking about membership scenarios with expiration, right? Yeah, I like that. And join, create membership entity. don't even need to say this, right?

Great, because we know what's in it, it's up there. Then I renew my membership.

@2:16:59 - estevenson

Thank you. You Such that it will remain active contiguously, this is not well-worded, update membership entity expiration date. If I renew my membership such that there will be a gap, that's probably good enough, then create new membership entity.

@2:17:53 - JD Leonard (modernbizconsulting.com)

Representing the future membership. Oh, kind of like other scenarios that I don't need to sort of, I don't know if they need special consideration is, I am, like, as an organization, I want to expire a particular membership type, but grandfather in people who are part of this membership.

@2:18:24 - estevenson

Do we actually care about that? I don't think we do. People can just do their own sort of maintenance.

But yeah, kind of that is an example where you could have something that is grandfathered, yeah, where the organization would consider it contiguous, but they, like, changed it.

@2:18:42 - JD Leonard (modernbizconsulting.com)

So I think the concept of, like, being a member of some sort at the organization contiguously is separate from whether a given membership is contiguous.

Okay. Okay. So let's add, I renew my membership at a membership, but at a different type, but of a different type.

Yes. Okay. If we renew, if we, if I renew my membership, yeah, okay, that's, that one's fine. Yeah, I'm just trying to think of other scenarios.

@2:20:06 - estevenson

I've got a weird one. Okay.

@2:20:13 - JD Leonard (modernbizconsulting.com)

Which I don't know that we need to do anything special about. It's just going to be a little odd.

@2:20:18 - estevenson

So if I renew my membership such that there will be a gap, and we create the new membership entity representing the future membership, and then I renew my membership such that there won't be a gap.

@2:20:36 - JD Leonard (modernbizconsulting.com)

Right? It's like it's... can do that. I can give my neighborhood organization... I don't think we've encountered this because it's a weird thing to do, but somebody could theoretically be a 2024 member, and then towards the end of 2025, they become a 2026 member, and then they're like, oh, wait, I'm not a 2025 member, and then they become a 2020 member.

@2:21:00 - estevenson

Five member, now they have conceptually backdates. That is a good edge case. But I don't think we need to do anything special.

It's like, okay, it's fine if there are some extra membership entities in that scenario. Like, what's the harm, right?

@2:21:18 - JD Leonard (modernbizconsulting.com)

Oh, kind of like if I've got some type of auto-renewal or kind of something that triggers off kind of a membership being active, and now I have two actives, so then I end up with stuff that triggers twice.

That's a good point. I mean, I suppose, you know, we haven't talked about anything about, like, the logic for which memberships you are allowed to renew when and stuff like that.

Like, that's all going to be very particular to each organization.

@2:21:47 - estevenson

But I don't see a better way of addressing this. I don't think we want to, like, merge memberships somehow.

No, I mean, I wouldn't want to merge. Merge memberships. mean, kind of either what I'd want to do is sort of add a check, is there a future membership, but then you'd also have to make sure it's like, is there a future membership of the same type?

If so, kind of like change my expiration date to its start date.

@2:22:18 - JD Leonard (modernbizconsulting.com)

The trick here, though, is like we're, we could look in either direction. It's like, well, we are, we're looking backwards and we're backdating this one.

@2:22:26 - estevenson

And so the previous one is contiguous with this one. And also the next one is contiguous with this one.

Panic. No, no, no, no, That, that, that is a painful use case and absolutely something someone could do. So I think we document it.

No, no, no, that's definitely document. Yeah, that, I mean, like functionally for our purposes, because like maybe they want to have kind of like the organization does want to have both memberships, act.

@2:23:01 - JD Leonard (modernbizconsulting.com)

And we just sort of document it for any implementation that this part of the sort of, this module doesn't concern itself with that, but modules building on it, probably need to worry about it.

@2:23:19 - estevenson

Yeah, maybe. Maybe so. Yeah. Kind of like, yeah, that's, that's, that's a little bit obscure, but, you know, kind of people are going to miss that and then they're going to complain.

But, you know, kind of, we are documenting that this is not, this is intended behavior and you need to, you need to have your module kind of address it.

Either that, or we kind of, you know, if we wanted to be nicer, we have different standardized behavior and we allow people to configure it per membership type.

Yes, I think, I think there is a goal to allow config. Considerability per membership type. There need to be plug-ins that you can choose basically from the behavior of.

I don't know what those look like, but. Yeah, so no, so yes, possibly a future plug-in that, you know, kind of, yes, we figure out kind of what are the standard sort of ways people want this to be handled.

Like, I think I can only imagine the three.

@2:24:24 - JD Leonard (modernbizconsulting.com)

And, yeah.

@2:24:26 - estevenson

So, yeah, I would agree. Leave this for now and make a note that this makes for a logical future plug-in to allow it to be configurable.

@2:24:55 - JD Leonard (modernbizconsulting.com)

Thank you. Yeah, no, no, I can think of another behavior where maybe you want it to prompt the user and just sort of like, oh, you have another membership that would conflict with this, do you want to delete the future membership?

@2:25:19 - estevenson

Yeah, no, I can imagine a bunch of different pages. Right. So yes, I would say kind of, I would agree that we just sort of leave it because like, from a functional perspective, in terms of the module working, it doesn't matter if you've got two active ones.

And yeah, just make it painful for anyone using this. And then if it becomes really painful, we make it configurable.

Yeah.

@2:25:53 - JD Leonard (modernbizconsulting.com)

Yeah.

@2:26:00 - estevenson

All right. Well, that was a weird one. Yeah, no, no, kind of. That was good thinking. What else do we have here?

I guess we could talk about upgrades and downgrades. Oh. Upgrades, downgrades. mean, kind of, can also, now I'm just imagining, oh, like, is there any weirdness for people wanting to enter memberships inside the past?

Where it's just sort of like, I, you know, kind of, this organization has updated to this system, and I'm just sort of doing this, and for some reason, I want to enter the membership I had before this was implemented.

@2:26:45 - JD Leonard (modernbizconsulting.com)

Is there any weird scenarios that happen there?

@2:26:48 - estevenson

I don't think.

@2:26:51 - JD Leonard (modernbizconsulting.com)

Yeah, I made a note.

@2:26:52 - estevenson

Let's come back to that one.

@2:26:54 - JD Leonard (modernbizconsulting.com)

So. Like, yeah, kind of one answer is we just don't let people do that. It's but you. But, well, mean, kind of from an import perspective, we definitely want to allow people to do that.

But, you know, kind of, you could have it that, you know, like, I'm able to prevent, like, I present sort of membership sort of papers that I was just sort of a member back inside, like, 85.

@2:27:20 - estevenson

And, you know, sort of, you need to do stuff about this, so you need to enter it, even though previously wasn't part of it.

Is there any weird behavior? I don't think there's any weird behavior. Right, that was just documenting the, like, upgrade case, right?

I might do I then change.

@2:27:54 - JD Leonard (modernbizconsulting.com)

Yeah, we need to do that here. I've never been a member or a new...

@2:27:59 - estevenson

... ... ... ... ... ... ...

@2:28:03 - JD Leonard (modernbizconsulting.com)

Yeah, okay. I know the flow of this is all a little odd and bullet points, but... Okay, sorry. You were talking about historical memberships.

Yeah, don't actually think we need to worry about it. I was just sort of, sorry, vocalizing, which probably shouldn't have been doing what you were writing.

@2:28:28 - estevenson

No, that's fine. Well, I mean, all right, what if we're dealing with overlapping memberships of the same type? Say, because it came from an external system we don't have control over.

Yes. Do we want to just allow that without complaint? I think, yeah, I think so. I don't think we need to do anything special, but like...

Kind of... I'm to think of what assumptions people are making about the cleanliness of this data and whether memberships, whether you can have two memberships that are active at a given time of the same type for the same contact for the same organization.

@2:29:21 - JD Leonard (modernbizconsulting.com)

We don't want to support that, but it could exist.

@2:29:26 - estevenson

Yeah.

@2:29:29 - JD Leonard (modernbizconsulting.com)

No, like for some reason, I really like this organization and I sign up twice.

@2:29:35 - estevenson

Do we just say that don't allow people to do that? But yeah, like you said, there could be imports.

And then kind of like, I want, I mean, I definitely think that this particular implementation should not handle auto-merging, which is sort of, yes, that I import kind of a historical membership, you know, like, do, do we have something that, you know, kind of...

@2:30:00 - JD Leonard (modernbizconsulting.com)

Do we even have kind of a historical importing functionality, or do we just sort of like, you figure that out when you write the code for your historical merge, or a kind of whatever module that like, I want a module that imports from Salesforce, because, you know, like, I would write something custom for Salesforce anyway.

Yeah, I mean, I think it would be fairly straightforward for us to provide like a simple CSV import of, you know, membership data, right?

@2:30:27 - estevenson

And, you know, I'm not sure what checks we put on that data when you import it.

@2:30:34 - JD Leonard (modernbizconsulting.com)

I mean, if I were being nice, I might, as part of kind of that, add a little thing, check for duplicates.

And if it does, then just sort of like generate an error log, and then you just sort of like give it to the person to figure out.

Or kind of like, just don't ignore duplicates, and then it does it automatically.

@2:30:57 - estevenson

Let's, let's defer. Let's Thinking on this scenario, because I'm just imagining, once we have the actual data model in place and built, right, then we might have a little more mind share to think about importing data and how that all, you know, how we might do that.

@2:31:20 - JD Leonard (modernbizconsulting.com)

But like, I feel like my brain is probably becoming saturated with too far in the future activities. I would agree that kind of for handling historical the furthest till it's more built.

Well, also, you know, when you create a membership, it also needs to result in member entities being created, right, for the relevant contacts.

And a membership is for a specified contact, so the contact needs to already exist in the system.

@2:31:53 - estevenson

So yeah, my temptation would be that you have a membership import, kind of. And that's its own separate thing.

then it figures out kind of like what logic it wants to import. Because this particular one doesn't need to have, like, the MVP of it doesn't need to allow for some type of automated import.

Well, you could import activity. You could import membership activity of some sort, right? So you could at least into the activity log say, hey, this person had a historical membership between these dates of this type.

@2:32:29 - JD Leonard (modernbizconsulting.com)

Right?

@2:32:29 - estevenson

Then at least you would be able to import something without having to have, oh, sorry, that's a membership activity.

But we don't have a membership entity.

@2:32:42 - JD Leonard (modernbizconsulting.com)

You could have activity on the contact saying that or something, right?

@2:32:49 - estevenson

I don't know if I just exploded our heads, but. I don't know. Part of me feels very tempted that, yes, that this doesn't handle it.

And then there is a separate. Membership import module, because there's so much to sort of figure out. And then, you know, kind of, and then that membership import maybe allows for kind of plugins, so you can create shims for different systems, and then it has its own CSV one, and it defines what that CSV will look like, and then, like, throws errors based on that CSV, and then you've got plugins so that, yeah, you can have your Salesforce shim, you can have your Workday shim.

Yeah. don't think you'd have kind of, I mean, Salesforce, just because they've got kind of, like, a non-profit edition, I could see that popping up.

I don't think you'd ever see Workday.

@2:33:43 - JD Leonard (modernbizconsulting.com)

All right, other scenarios for memberships with expiration dates? Um, oh, just trying to sort of, like, brainstorm, you could have dead man switches.

need It's美國 that's Where kind of like for this membership type, if you have not kind of like attended for XYZ, it will expire.

I don't know if we want to deal with Dead Men switches, but that is a scenario I could see popping up.

I mean, more generally, right? You're just talking about a cancellation of a membership, right?

@2:34:20 - estevenson

Yeah, cancellation of a membership that, and I think that falls under you guys figure it out. we don't kind of, I don't think there needs to be special, yeah, I don't know if there needs to be special handling of it for a Dead Man switch.

@2:34:38 - JD Leonard (modernbizconsulting.com)

Well, I don't know about the Dead Man switch, but just in general, right?

@2:34:42 - estevenson

Like something triggers the cancellation of membership, whether it's the contact, like the member, or whether it's an administrator, right?

@2:34:52 - JD Leonard (modernbizconsulting.com)

So then the, I think the membership, where is it?

@2:34:58 - estevenson

We just update the expiration. Expiration date, right? Or is the expiration date remaining the same, it's just the status that changes?

Like, can you have an inactive membership with a future expiration date?

@2:35:14 - JD Leonard (modernbizconsulting.com)

Maybe. Maybe that's more descriptive, because you could then, like, I don't know, uncancel it.

@2:35:21 - estevenson

But yes, I'm just sort of imagining that you cancel something and go, oh, shoot, wrong person, and then you need to revert it.

@2:35:28 - JD Leonard (modernbizconsulting.com)

So I think you don't update the expiration date, you update the membership entity status. Mm-hmm. And I think status we need to define better, right?

@2:35:40 - estevenson

Yeah.

@2:35:51 - JD Leonard (modernbizconsulting.com)

But broadly, right, your membership is canceled or suspended, we update the status. Yes. And then we don't change don't the sort of that.

Because that makes undoing a lot simpler.

@2:36:04 - estevenson

Otherwise, you have to go to the log and kind of sort of, yeah. Same when it expires, right? It expires, the status gets updated.

It also sort of handles that I have a lifetime membership, and then I cancel it, and there's no expiration date.

@2:36:27 - JD Leonard (modernbizconsulting.com)

Yeah, good point. Okay, it has been brought up both on this call and in my call with Steve, the concept of pausing a membership.

Mm-hmm.

@2:36:44 - estevenson

If a membership is paused, presumably that is a change in the status of the membership, and any changes to expiration date would be specific to whatever is pausing.

Okay. So it's more just about that there needs to be a status for pause or something, right?

@2:37:08 - JD Leonard (modernbizconsulting.com)

Yeah, no, and possibly kind of like a standard way to log it so that, you know, like, because yes, we're sort of defining membership activities that there's sort of, we built in our own sort of plugin that such that, know, kind of, this is how you'd be able to access when the pause started.

@2:37:32 - estevenson

Active, future, paused, expired, canceled.

@2:37:40 - JD Leonard (modernbizconsulting.com)

What are we missing? Nothing I can think of that wouldn't be represented by just giving the person a different membership that you could have, like, yes, that it gets downgraded because you didn't show up enough.

@2:37:58 - estevenson

But, you know, kind of, yeah, I don't think that.

@2:38:00 - JD Leonard (modernbizconsulting.com)

It deserves its own status. Smart.

@2:38:13 - estevenson

What's interesting, suspended might be a better word for paused.

@2:38:17 - JD Leonard (modernbizconsulting.com)

Yeah, suspended is better.

@2:38:18 - estevenson

More general.

@2:38:27 - JD Leonard (modernbizconsulting.com)

We have inactive or lapsed. We have expired. I think expired is good.

@2:38:46 - estevenson

Oh, that's interesting. Pending activation. That seems like a good kind of one, right? Draft is also potentially a good one.

Draft Yeah, maybe. What does it mean to have a draft membership, though? That someone started filling it out and then didn't finish?

I think we can probably skip that. It's like, if you can't come up with the contact and the membership type, what are we saving for you, really?

Like, there's not much to save, right? Yeah, no, no, no. It's not complicated.

@2:39:22 - JD Leonard (modernbizconsulting.com)

And if there was complexity, that would be a part of a different module. I wonder if pending activation is the same as future, or if they're distinct.

@2:39:40 - estevenson

Well, with future, that implies that we know it will kind of start at this time. With pending activation, we don't.

Like, I am thinking of, like, waiver, where kind of, like, someone has started it. Yeah, like, you could actually have a future one that's pending activation.

So, kind of, like, I apply for, kind of...

@2:40:00 - JD Leonard (modernbizconsulting.com)

January next year, I also must sign this waiver. I don't sign this waiver. So that you'll kind of, yes, then it logically doesn't start.

@2:40:10 - estevenson

Well, start, yeah, kind of active future probably implies that. So yes, you could have a future one that is also pending activation.

@2:40:21 - JD Leonard (modernbizconsulting.com)

I see what you're saying. Yeah, that almost makes me wonder.

@2:40:30 - estevenson

I don't love it. But that covers the case, right? Yeah, yeah. I mean, hmm.

@2:40:48 - JD Leonard (modernbizconsulting.com)

But yes, okay, so let's say it's pending activation, and then I activate it. Does that change the start date?

Because the pending activation sort of implies that. I had the same thought. I don't. I don't Your activation might almost be its own field.

I don't actually know if it should be its own field, but if you're having kind of like it effects statuses.

So for... Hmm. I mean, I think this is good. You know, kind of, we're just sort of thinking of edge cases that might come up.

Yeah.

@2:41:38 - estevenson

I'm happy to leave it there.

@2:41:48 - JD Leonard (modernbizconsulting.com)

I think we're doing pretty well there. Yeah. Let's see. And so these are probably like workflow states on the membership, which affords for permissions to transition between different states, and which states you can transition between, right?

Hmm. I'm a little torn on the added complexity and power. Of content moderation, kind of workflow states for this stuff versus just sort of a flag.

Yeah, no, mean, kind of like we could keep it simple and just sort of like and leave future states.

Because, mean, we can always add more states or statuses.

@2:43:19 - estevenson

You know what it's...

@2:43:20 - JD Leonard (modernbizconsulting.com)

Let's see. I mean, you know what it is, you know what it is, is I think there could be, there's sort of like a, there's a concept of like, there's a concept of is this active, right?

@2:43:50 - estevenson

Which is if it's active or pending cancellation. Right? Like in either case, it's active. Yes. could just look at the start date.

So it's something that could be extrapolated. Because, yeah, no, and if you make it kind of like a direct status, then you're going to have kind of cases where someone changes the status to future when, you know, kind of the start date's inside the past.

You can prevent people from changing the status to things that don't make sense, right? But it's an interesting point about just removing the future ones here.

@2:45:30 - JD Leonard (modernbizconsulting.com)

Is a, if you have a future membership, can it be in the active or pending activation status, assuming the future ones are not listed?

Are either of those valid, or is only one of those valid? Do we want this to even handle kind of pending activation?

Or kind of like future pending activation?

@2:45:58 - estevenson

Or kind of like,

@2:46:00 - JD Leonard (modernbizconsulting.com)

Is pending just something that it just, it's assumed to be currently active. Because yes, I mean, I was the one who sort of brought it up, but yeah, that's just a scenario.

Is that something that, you know, kind of should be left out unless someone wants to put a future plug in or do their own thing?

@2:46:24 - estevenson

I guess if we remove these, conceptually, you could have a membership that starts in the future that is pending activation or that is not pending activation, i.e.

@2:46:42 - JD Leonard (modernbizconsulting.com)

active. But it's confusing if you just do a query like, hey, is it, give me all the, like, does this person have an active membership?

Conceptually, they don't if it starts in the future. Yes. Maybe it's currently active. But then if you have a, then what status is a future membership in?

@2:47:21 - estevenson

So maybe status approved? Hmm. Because you kind of, you can be approved, but not active. So then a flag for is current, right?

@2:47:47 - JD Leonard (modernbizconsulting.com)

It's like, would, would be if, within.

@2:47:59 - estevenson

Then. Mm-hmm. Window of start date, and expiration date, and status is approved.

@2:48:11 - JD Leonard (modernbizconsulting.com)

Yeah.

@2:48:17 - estevenson

Something like that? Oh, kind of.

@2:48:21 - JD Leonard (modernbizconsulting.com)

Like, the one thing that cups to mind is it's... Yeah, because, yeah, no, you've got suspended. That covers the pause situation, because then it's not active.

Yeah, so I think just a calculated bool.

@2:48:37 - estevenson

Would it be as current or as active? Could be active. It all just comes down to defining what this means, right?

Yeah. Yeah.

@2:49:01 - JD Leonard (modernbizconsulting.com)

Oh, wait, wait, and status is approved or pending cancellation. Okay, good catch. And now you've got a source of truth, whether it's active or not.

Right, because you don't want to replicate this logic everywhere else. Just imagine creating views where you're like, is it within the start date and the expiration date?

But also it depends on if there is an X, like if there is a lifetime membership, it's like, oh, no, no, no.

Yes, we just, we define the states where something is active and then that's just, it's just a Boolean field.

I like that. And then that kind of.

@2:49:47 - estevenson

That works well. And then if you want to add other states, you know, kind of states where it is active, then that provides a place to change it.

Without kind of having to redo all your views.

@2:50:00 - JD Leonard (modernbizconsulting.com)

Well, what I don't... Oh, I see what you're saying. Yeah.

@2:50:04 - estevenson

I'm wondering, though...

@2:50:06 - JD Leonard (modernbizconsulting.com)

I'm wondering...

@2:50:09 - estevenson

I guess you could have configuration in the system that says which of these counts as active if it's within the window.

Yeah.

@2:50:26 - JD Leonard (modernbizconsulting.com)

Right? Right? So, I mean, to poorly put it, right? And if you need to add another one, you can check the box that it counts toward active.

It's rewording, right? Yeah. Then, yes, that makes it easy to add new statuses that this counts as active. Okay.

Okay. I'm sorry. Okay. Bye. Flag as counts as active? What did you say? Oh, I'm just sort of like, counts, flag as counts towards active, but I think that's me being picky.

Here's my question.

@2:51:40 - estevenson

Should these statuses be built in and immutable, essentially forming an API, you know, contract for like what the status of a membership can be?

And can we envision a world where there are other statuses here? I know I brought up something like an approval workflow, right, with multiple steps and this and that, but that could just be a separate workflow that impacts the status.

@2:52:19 - JD Leonard (modernbizconsulting.com)

It might be easier that these are just immutable and you can't sort of add new statuses unless you're willing to hack it in.

And yeah, that does simplify it. Because then external systems can make some assumptions, right? Like they can trust that these will be potential options and that there are not other potential options.

let's just not make it configurable. That is a good idea.

@2:52:56 - estevenson

Thank you.

@2:53:00 - JD Leonard (modernbizconsulting.com)

Thank you. Can we talk about membership types a little bit? Mm-hmm.

@2:53:59 - estevenson

Oh, hold Hold on. Sorry, back to, no, that's okay. Okay. Yeah. Membership types. So a membership type is for a specific contact type, person, household, organization.

Yeah. like, I mean, I can conceive of that not being immutable, but I, yeah, we should make that immutable that it's only for one type.

And then if you want something to kind of count for both a person and organization, you just create overlapping ones.

@2:54:40 - JD Leonard (modernbizconsulting.com)

I like that role. Well, yeah. Either you have separate membership types or you have a membership type that covers, you use relationships, right?

To derive members from a membership, right? But yeah, like I'm thinking kind of, you've got kind of an individual developer relationship versus.

Kind of, if you've got an organization one and those are just within the system, yeah, they're two different things, even if they give the same kind of permissions.

Yes. One moment. Yeah.

@2:55:17 - estevenson

Yes. You need a hug.

@2:55:35 - JD Leonard (modernbizconsulting.com)

Nice. So a membership, okay, so concept of durations. So either we say you need a separate membership type for each membership type that has a different duration, right?

It's like an annual standard.

@2:56:03 - estevenson

Or we say, no, that's just a standard membership, and maybe you get to choose what the available durations are for that membership type.

So, yes, so you're saying that if I wanted both a monthly and yearly version of this sort of like membership type, I would create two types.

Well, there are two different ways to approach it. We either create two types, or we say there's one type and it has two possible durations that you can select, right?

You choose both of them.

@2:56:50 - JD Leonard (modernbizconsulting.com)

Then it means when creating a membership, you would need to choose from the available durations.

@2:57:02 - estevenson

Right?

@2:57:05 - JD Leonard (modernbizconsulting.com)

Well, like I know definitely when I am, when it comes to kind of like selecting member, like I'm either going to be monthly or yearly, you know, kind of like, so to me it makes more sense that you have, or at least it would be easier to implement, is probably a better way to say that.

It easier to implement both the kind of like monthly and yearly as two different things. Two different membership types.

Yeah. I agree. That would definitely be easier to implement. Yes.

@2:57:40 - estevenson

You know, kind of, which doesn't necessarily mean that's how you should do it.

@2:57:45 - JD Leonard (modernbizconsulting.com)

Yeah. I'm not, I'm not sure what the better route is here. Let's explore the more complicated one and see if there's a virtue to it.

@2:57:54 - estevenson

Right. I mean, I guess one virtue is you don't need to create I Multiple membership types. Yeah.

@2:58:04 - JD Leonard (modernbizconsulting.com)

But if you're looking at a given membership, right, you want to understand is it a monthly or annual membership?

You can't simply examine the start date and expiration date and do math because that can change for various reasons.

@2:58:20 - estevenson

So we would want to track on the membership what the duration, effectively the duration type, right? It's like the duration type is of the membership because that wouldn't be stored on the membership type.

@2:58:36 - JD Leonard (modernbizconsulting.com)

You just have the possible options stored on the membership type.

@2:58:42 - estevenson

So when it comes time to renew, you would look at the membership, the duration type on the membership to know how to prompt them to renew or whatever.

That, yes, having them be different things does make the kind of like, yes.

@2:58:59 - JD Leonard (modernbizconsulting.com)

some experts us with makes it easy to automatically calculate kind of when their expiration date should be. It also allows you to change your change between monthly and annual without having to create a new membership.

Hmm.

@2:59:26 - estevenson

Yeah. No, that helps you preserve kind of like contiguous sort of contiguousness. Yes, but I also am not convinced in the value of that contiguousness.

Yeah, no, I mean, I'm not convinced either. Kind of. I could imagine it being someone something. Yeah, I could imagine it being something someone could request, but you can hack.

You can just hack the sort of like logs to do it yourself. Yeah.

@3:00:01 - JD Leonard (modernbizconsulting.com)

I guess, hmm. Yeah, like, I'm. of edge cases. Go ahead. Yeah, no, I'm struggling to think of an argument to just not have two different membership types.

What if, I don't know if this is a real thing, choose your own membership length, duration?

@3:00:25 - estevenson

Oh.

@3:00:31 - JD Leonard (modernbizconsulting.com)

That's interesting, because, like, well, no, no, no, I mean, I could definitely see that, you know, kind of, I can volunteer at this organization until this date.

And, you know, kind of knowing that ahead of time. But, yes, you know, kind of, you could have someone, like, I'm going to move away at XYZ, and you come to a agreement.

@3:00:54 - estevenson

So, yeah, no, choose your own length is a thing. I mean, I hate to get so out in left field here, but I mean, does this mean we would need like duration plugins that could support things like choose your own duration, choose your own expiration date?

@3:01:27 - JD Leonard (modernbizconsulting.com)

Um, maybe that, yeah, kind of as a type, you could just have like custom duration. Um, but I mean, it also means like, I mean, that it could incorporate whether it's a lifetime membership, like that would be a different plugin type for the duration.

But yeah, like I know functionally, you could just give someone, you know, kind of that yes, as an organization, if I needed to do this, that I'm also thinking like, who are we targeting with this?

@3:02:00 - estevenson

Um, you know, you could just give someone a lifetime membership and then manually cancel it kind of at that start date.

Is this something that we need that, that there's a lot of value having the system manage it for people kind of like relative to just sort of trying to like the extra interface?

Right.

@3:02:17 - JD Leonard (modernbizconsulting.com)

I'm also thinking about at some point, member platform is going to have like, probably like prices associated with memberships, membership types.

And it's definitely more complicated to deal with prices per duration per membership type than just prices per membership type.

@3:02:44 - estevenson

Right. So if you've got a different membership type for annual and monthly and lifetime, let's say, it's very simple to just associate the prices with those.

Yeah, no. And for the, yeah, like. I think with the custom, people can do that manually managing the system, and I think that's a rare enough case that there isn't a lot of value, and at least sort of a default implementation allowing people to do that.

I mean, it's also fair to say, like, hey, that belongs in the billing system piece, not in the representation of the memberships.

It, yeah, and in fact, I don't know, does, does duration live in the billing side of things? Well, I mean, I can think of volunteer organizations where there's no money exchanged, but, or like, yeah, where, I mean, it's based on attendance, or it's based on kind of volunteer shifts, whether...

Right, that's, yeah, I think you just summarized it right there. Do we care about duration for any reason other than money?

Mm-hmm. So, yeah, like, I could imagine dead man switches where kind of if a person hasn't, and yeah, this isn't what we'd implement.

This is just me trying to think of scenarios. If a person doesn't attend every three months, then you deactivate kind of their online resources for X.

So you could have attendance-based.

@3:04:56 - JD Leonard (modernbizconsulting.com)

There's volunteer shift-based.

@3:04:58 - estevenson

Um, you could have to.

@3:05:00 - JD Leonard (modernbizconsulting.com)

Kind of, like, regularly kind of sign a waiver-based, where, like, you have to go log in online and click this, and if you don't, then, you know, kind of, you're no longer agreeing to this, so we can't, like, take you skydiving with tigers or something.

@3:05:15 - estevenson

I mean, then your membership goes into pending activation or something, right? Yeah. You're suspended.

@3:05:21 - JD Leonard (modernbizconsulting.com)

Depending on the circumstances, right? Yes, mean, there's also kind of, like, as a moderator, like, you, we went to a, we organized an event at a restaurant, and you ran out on the bill, and I had to pay it, and I'm going to put you inside, kind of, you know, kind of paused until you get back to me with the money.

So that, you know, kind of, if you go online, that, so yes, you could want to manually change it based on member behavior.

@3:05:55 - estevenson

Sorry, manual change what? Sort of, like, I mean, there's a... Also the case of someone wanting to manually cancel or suspend someone's membership because kind of due to misbehavior or something.

Whatever the reason, doesn't matter. Yeah. Kind of independent from money, I might want to track approved, all that, like the same way that...

@3:06:20 - JD Leonard (modernbizconsulting.com)

that's different than the duration that they have signed up for, right? Yes. I guess it's relevant to understand the, for lack of a better word, intended duration of a membership.

So that if you... Well, no, I don't know. Yes, mean, you could have that sort of, the eventual billing is dependent on this module, and that module has duration kind of associated with membership types, and this just...

@3:06:59 - estevenson

know. Doesn't have that. I guess it's just sort of like, should, yes, which module's responsibility should that be?

@3:07:08 - JD Leonard (modernbizconsulting.com)

It's convenient having it inside this one because then you don't, you can have the data inside one table.

@3:07:17 - estevenson

So imagine an organizer is going to manually add a membership into the system and get to the form to add the membership and, well, they've got the flexibility to set the start date and expiration date to whatever they want, right?

@3:07:36 - JD Leonard (modernbizconsulting.com)

But they probably would at least like it to default to something, right? So does a membership type have a default duration that can be overridden, you know, by the organizer?

That's another approach. So kind of, yeah, for this membership type, it lasts a year. And then we don't, I mean, that would also allow us to not worry about...

Renewal. Or do we have to? I'm going to type this for now. Default Duration, and that's lifetime or time interval.

So kind of weekly, monthly, yearly.

@3:08:29 - estevenson

Theoretically, like, bi-weekly.

@3:08:33 - JD Leonard (modernbizconsulting.com)

There's many versions of time. Right. We don't have to worry about the widget, right? It's, yeah, okay.

@3:08:42 - estevenson

So if we set a default duration, an organizer goes to create a membership. It's prefilled, right, based on the start date they select.

The, if they choose a time interval, you know. Add that to get the expiration date, right?

@3:09:06 - JD Leonard (modernbizconsulting.com)

We're not going to enforce that on the organizer, right, if they have the permissions, relevant permissions, right? That means, okay, so let's say this membership is up for renewal.

@3:09:36 - estevenson

Renewal is a billing thing, so we ignore it here.

@3:09:40 - JD Leonard (modernbizconsulting.com)

Is that kind of what we're saying?

@3:09:42 - estevenson

Well, I mean, kind of like as an organizer, I might still want to have a button I can click to renew the membership, independent from billing.

That, you know, kind of maybe I don't want to use the billing module, but I want to be able to sort of, and I want to manually manage that manually.

So I want to... I mean, you can go to edit the membership, right? We could create simpler, more user-friendly forms that let you do the same kind of thing.

But I think what I'm getting at is, do we need to track any data here to facilitate that? I mean, unless there is behavior driven by kind of like duration and expiration date, then no.

But I mean, I think, yeah, for this module, it's just informational. So people can kind of refer to it to know if it's expired.

And then there will be modules that use that information. Yeah. Yeah. it's HAB. Yeah.

@3:11:02 - JD Leonard (modernbizconsulting.com)

Sorry, now I'm just trying to run it by. That pretty much, yeah, should duration belong more to the billing module.

And just sort of like for this, we just have a default. I think that might be the place to start.

That would make sense. And then, yeah, you can kind of reduce the complexity of this particular thing that, yes, it is nice to be able to sort of have it default.

@3:11:36 - estevenson

And then, yes, inside the user interface, you could have just sort of renew membership. And then that's able to kind of, again, default it to, you know, kind of like whether the relationship defaults to monthly, yearly.

Yep. Like sort of the renew button. But yes, kind of a magic use case where someone is using this without wanting to bill.

So I added specific date as another possible default duration setting, which affords for I have a 2025 membership that expires December 31st, no matter when you do it, right?

@3:12:21 - JD Leonard (modernbizconsulting.com)

Now, it's a default duration, so you could imagine that, but, you know, maybe this default duration needs to be updated once a year, right?

So that it continues to be useful. Yes. Which is a bit wonky, but like, okay, right? Yeah. This lasts as long as the pool is open.

@3:12:47 - estevenson

You know, kind of that, you know, I'm just sort of imagining that, yes, you have something that's at sort of like to use a resource that's time limited, then it would kind of like every single year and at the same date.

@3:13:00 - JD Leonard (modernbizconsulting.com)

Um, regardless of how long you signed up or, yeah, that makes sense to me. Specific date, current year. That means you don't have to update it every year, right?

@3:13:16 - estevenson

I don't know if you would have specific date following year as like another option. I don't think so.

@3:13:25 - JD Leonard (modernbizconsulting.com)

I'm thinking of like, uh, I don't know, some like frequent flyer programs and membership programs.

@3:13:32 - estevenson

Sometimes your, your like membership, your status or whatever is valid through the end of the next year, but something that could be added.

Thank you. I don't think so. You So, yeah, okay. I'm wondering, yeah, would that sort of like next year be covered by fixed versus rolling?

Well, what I was just wondering is, is fixed versus rolling covered by what we just described?

@3:14:40 - JD Leonard (modernbizconsulting.com)

And kind of like how does, without billing, how does rolling work? That you're kind of like, if there's no defined end date, and you're kind of, you're not charging for people to kind of like buy month by month, isn't lifetime effectively just rolling?

you. Maybe we can remove this and add a default start date. Yeah.

@3:15:08 - estevenson

Does that cover it? I think so. Start of month.

@3:15:29 - JD Leonard (modernbizconsulting.com)

Oh, nice. Yep. I guess specific dates to be a current year. Specific date, current month. Right?

@3:15:53 - estevenson

That lets you say, basically backdate it to the first of this month. were. date? Hmm. Yeah. And we probably also need next month, right?

So start on the 1st of the next month. Mm-hmm. Yeah, no, and then, yeah, time interval can just be relative to whatever the default start date is.

What about a default start date that is based upon a previous or existing membership?

@3:16:48 - JD Leonard (modernbizconsulting.com)

I don't know, that gets too complicated. I mean, what I would be worried about is, you know, kind of my default start date is a specific date, but then my sort of, like, default duration.

a a moment. moment. You is like a month, so now kind of like the form which you use to sort of edit it is going to have to update depending on whatever the person puts inside the start date.

So like I might say that if you're entering a specific start date, you have to enter a specific end date just to remove that calculation.

Unless we want to have that calculation. But yes, you understand kind of what I'm saying, that if you allow a specific start date, then that implies that the default duration is relative to whatever the person enters.

So it could change. Or kind of, yeah, the end date calculation could change. Well, okay, so let's take a specific start date and then look at each of the default duration options.

So if the specific start date is... And it probably doesn't matter, right?

@3:18:02 - estevenson

We just choose a specific date. Let's say February 1st, right? If the default duration is lifetime, no problem, right?

We know what the start date is, we know it's a lifetime membership. If it's a time interval, like a month, well, that's the other thing is, oh, no, that's fine.

@3:18:33 - JD Leonard (modernbizconsulting.com)

I mean, I'm just going to note, time interval must include month, right? Calendar month as an option, right?

@3:18:43 - estevenson

Which is different than 30 days, right, for example. Yeah. So you include a time interval, and that causes the end, the expiration.

Yeah, so I've created a membership type. I enter kind of the default start time, you know, kind of manually, and I've set kind of the time interval to be kind of a month.

Then kind of, that means the default ending would, well, no, because, I mean, you'd be calculating the ending when the person creates the membership.

So that's potential.

@3:19:27 - JD Leonard (modernbizconsulting.com)

Well, can, based on the date in the start date field, right, we can dynamically update the calculation for the expiration date before the form is submitted, right?

I guess kind of, okay, where I'm getting confused is that I can create the membership type, and I sort of select specific date.

Does that mean that there's now kind of, I enter the specific date on the create membership sort of thing, or they're kind of a separate form that now.

Yeah, so I've created a membership type. I enter kind of the default start time, you know, kind of manually, and I've set kind of the time interval to be kind of a month.

Then kind of, that means the default ending would, well, no, because, I mean, you'd be calculating the ending when the person creates the membership.

So that's potential. Well, can, based on the date in the start date field, right, we can dynamically update the calculation for the expiration date before the form is submitted, right?

I guess kind of, okay, where I'm getting confused is that I can create the membership type, and I sort of select specific date.

Does that mean that there's now kind of, I enter the specific date on the create membership sort of thing, or they're kind of a separate form that now.

@3:21:00 - estevenson

Now I've kind of created a type, and then for this membership, I'm now entering, yeah, no, no, no. So some of these is sort of what, some of this would change sort of what goes on the membership form.

Because, yeah, if we select specific date, that means when I go to the membership, create a membership, I will have a kind of a field that demands I enter a specific date.

@3:21:27 - JD Leonard (modernbizconsulting.com)

Well, so I think the field for an organizer, right, we're not talking about a member, but for an organizer, they would have a field for start date, and they would have a field for expiration date, and then there would be a field for as expiration date, which hides or shows the expiration date field.

Yeah. And based on the defaults here, right, those would be prefilled. Okay, and then I could override it on the membership.

Okay. Correct. So it's just about how it starts out, and, you know, you could make an optimization for the user experience.

you. Thank instance, say, if you manually adjust the start date on the membership form, then it recalculates the expiration date based on the default duration, right?

@3:22:12 - estevenson

Unless you have manually adjusted the expiration date. Because I think all of these still work, right?

@3:22:24 - JD Leonard (modernbizconsulting.com)

So if you do specific date current year, you say February 1st, and you're basically saying that this membership is, it's a seasonal membership.

@3:22:35 - estevenson

It's for, you know, February through June or something, right?

@3:22:39 - JD Leonard (modernbizconsulting.com)

Then you say June 30th current year is your specific date for the duration. Then by default, you're going to get a February through June membership, unless you manually adjust on the membership form.

@3:22:58 - estevenson

Do you still have concerns with No, no, no. So kind of, yes, we're doing the kind of like default, basically default duration on, yeah, like that's just what automatically gets calculated.

@3:23:11 - JD Leonard (modernbizconsulting.com)

And so then if the person changes sort of the start date on the membership, it doesn't auto update the kind of future date based on that.

@3:23:19 - estevenson

So, yeah, okay.

@3:23:21 - JD Leonard (modernbizconsulting.com)

I think, I think. And so in, for member platform, right, we would have some logic that provides a member facing form, right, for joining or for renewing that would have whatever logic it needs to have, right?

And would programmatically create, you know, a membership with the appropriate start date and expiration date. Not based, probably not based on these defaults here, but based on something specific to member.

I'm not 100% sure about all that, but... There'll be more than one pass on this. Oh, for sure. But yes, right now it's looking kind of comprehensive to me.

It's looking pretty good. Mm-hmm. All right. Well, I think I might pause there. Yeah. No, no. Kind of. I was glad to get to do kind of like via attrition another one-on-one with you.

Yes. Very good. We'll set up another one soon. Let's see here. I could probably do another one tomorrow if you're interested.

Yeah. No, I could probably do tomorrow. Yeah. could probably do probably Double checking. Yeah, no, no, no. If we're, if we're doing it inside the morning, you know, kind of the same time we're doing this, I could do tomorrow.

Alrighty. I'll, I'll shoot you an invite. Okay. Thanks, Erica. Have a great day. You too. Bye-bye.