Name: Ask the Expert about Reports in eTapestry
Uploaded: 2025-08-12T18:31:26.912Z
Duration: 56 min 20 s
Description: Ask the Expert about Reports in eTapestry

Transcript for "Ask the Expert about Reports in eTapestry": Hello, everybody. Welcome to this month's ask ask the expert session here for etapestry. Always happy to see, folks coming in here. Hi, Addie. That's, yes. Happy Tuesday indeed. I'm particularly excited this Tuesday because, as you mostly know, we do these on Wednesdays, but, we can't do, can't do that here this week because I am going to be out of the office starting tomorrow until next Thursday. I'm headed to Chicago for Fan Expo. So, looking to have some good times there and, be able to, pick up some more of my comic book collection there. But, but no. I just wanna say, you know, thank you for everybody who, comes to these. And, thank you for everybody who is saying hello in the chat. It's always great to hear from you. We're going to be primarily covering, more stuff around, like, reporting, which is what we talked about, you know, the last week in the, webinar. There are a few things that I was, specifically, wanting to kind of clarify or talk a little bit more about in terms of the, of some of the little things that I talked about in the setup of a report and some of the, what might happen if you select some something for a report, what it would mean to or what the results might be showing you versus, what might happen if you try to, run a journal entries report with an account return type query and stuff like that. So there will be a few things like that that I will be, kind of going into a little bit more detail and really kind of, hopefully, clarifying a little bit for everybody. But also, feel free at any point in time to ask your questions through chat. I'm more than happy to, answer what questions there are. I always like to come prepared with a little bit of stuff, but also, like, to answer as many questions as I am able to with our time here, each month. So, so with that, let me go ahead and pull up my database here. You should be seeing that on screen now. So one of the things I wanted to, talk a little bit more about was, you know, let's go into those queries that I had created. Again, they were very, very basic queries. They were just the journal entries from, from my account or my account alone. So, you know, like so this Jeff account really is just looking at a data return type of accounts. I used my account number. So in my database, account number 61 is my, donor account. So, you know, that's how I built this query. Now you could also use other things like, the account name. You know, you could've I could've used that and put my name in there or whatever, but I just went with the account number. So like I said, pretty simple. The key thing I wanted with this query as it pertained to our reports that I showed last week was this data return type being set to accounts. Okay. Similarly, if I go back a step here, in my Jeff transactions, I just wanted to, get my account number again and all of the journal entry transactions that I had in my account. And the key thing here again was to set the data return type to journal entries. So I wanted to kind of talk a little bit about that because I wanted to show a couple of different things that might happen with reports. And in particular, how I talked about things like summary fields or how I talked about, the aggregates on certain journal entries, or on journal columns rather. And I also wanted to specifically clarify something about, like, what happens if you are creating a report that has columns for journal entry information, but you ultimately use an account return type query. So I wanted to, again, like I said, kinda set the stage here a little bit about what these queries involve. So let me go into my reports now, and I'm gonna go into my account report here. Now remember, this is just right now, just kind of showing the and I have the summary fields here. I'm gonna go ahead and remove these also, and I'm gonna remove the account type as well. But, so when we were doing the session last week, I you know, this was the original version of this report. It was the account name, the address lines, the city, state, the postal code, and the sort name. Right? So what I wanted to to kind of illustrate here is what happens if you also decide to put in date and received. Okay. So I've got all of these fields. I've got date and receive, and I go to save and run. And if I still go with my Jeff account query here oh, accidentally cleared that out. But if I still went with my Jeff queries, Jeff account, query field here where it's all account or it's just the account information, my account in this query, when I display the results on screen, you'll notice that the date in received isn't showing anything. And that's why it's really, really important to understand what an, what the data return type in a query does. Right? So this Jeff account query was an account return type query. Meaning, it's only pulling the account information here. The account name, the address lines, the city, state, postal code. It can't pull specific journal entry information. Now as I illustrated last week, we could come in here and pull in a summary field. Right? We can say, okay. Well, give me the lifetime received total. And when I run this report here and submit it on screen, the summary field, because it is coming in from the account information, is able to pull that information. But the specific journal entry fields, date, received, fund, campaign, approach, all of those are not, available to display information from an account return type query. So whenever we talk about return type when it comes to queries in particular, It becomes important with what can be pulled into a report or into a communication because if you just want to get account fields, then account return type query is the way to go. Or if you're just sending out a mailer like a, like a newsletter or something through the communication section, accounts works fine for the data return type for the query. But if you ever need to display specific journal entry information, then you need to make sure that your query is set to journal entries return type because that's where date, received, fund, campaign, approach, the gift type, any defined fields specifically assigned to a journal entry, that's where you will be able to get that information from. And to go into a little bit more detail about where that summary field information is found and why that's not considered a quote unquote journal field even though it's providing, transaction information. If I were to click on my account here, this account giving summary is where the, where some of these fields, like year to date, last calendar year, last fiscal year, fiscal year to date, lifetime, those are summary fields there as well as this account five year summary. These are where all of those summary fields that are available in that report category can be pulled from. So this this is account information. But, yeah, if I wanted to get, like, actual specific journal information, then I would need to make sure that my query is set to journal entries as the data return type. So I wanted to clarify that a little bit because I know somebody had asked during the session last week about how they they were trying to, get information about, like, their their giving or the donors giving. And they could get all the account information, but they couldn't get any of the giving information. That could be and that's usually the number one reason why is that that data return type of the journal itself or of the query itself was not set to journal entries. It was set to accounts. So it could pull all of that account information, but none of the journal information. Something else I wanted to highlight was another question that came in. Somebody had said that they were pulling information. The query was pulling specific, entries, from a specific fund. But when they were pulling the query or they were pulling the report rather, the query's information was not adding up to what the report was showing. In other words, let's, let's go into my query again here for Jeff transactions. They were pulling all of the journal entries that were, like, let's say, to this general operating fund. Okay? And if I preview this query, Cindy, it was you. Yes. So we're we're talking about that right now. So here in the query preview, you'll see that from my account, I have, $2,820. Right? So now if I were to go into my reports and now I say, okay. Now I wanna pull all of those, or I wanna pull all of the accounts that gave to that journal or to that fund. I have the journal entries from that fund. Now I wanna be able to see the grand totals from everybody. If I go into my journal report and we're gonna do we're gonna group by account. We're gonna collapse groups. Let me remove all of this just to be safe here. We're going to say, okay. We're gonna get the address lines. We'll put in city. We'll put in state. And postal code, we'll put that in there. And, let's say then from here, I go into summary fields and I say, okay. Let's show the lifetime received. And just for fun here, we're gonna come back here and we're gonna pull regular received. Okay? Just to illustrate a point here. Now when I save and run and I use my transactions, now the received matches my query. Right? It says 2820. That was what was in my query. The lifetime received shows eighty two seventy, which is my lifetime giving. It goes beyond what the query's, scope was because, again, the lifetime received total comes from the summary fields. Okay? And the summary fields end up pulling from the account as a whole. It goes beyond what the, journal entries and the queries results are. Re received shows the exact number I'm looking for, but lifetime received stretches out beyond. So just remember that if you use a query that says I wanna find everybody who gave to a specific campaign, a specific approach, and so forth, then what you will do is, wanna make sure that you will, in the report, use received, not lifetime received or any of the other summary fields. Now Cindy asks, can you do the same thing with one year ago, two year ago, three year ago? Absolutely. So if I come back into my report here, let's knock off the, that summary field. And we'll say total. And we'll come down here and we'll add additional received, and this is where you use those aggregates. So we'll do year to date for the this one, and we'll add another received and we'll say last year. We'll come in here and we'll add the aggregate for one year ago. And just for good measure, we will go ahead and add two years ago as well. So now we have the received selected multiple times and then we're utilizing the aggregate in this case. Aggregate is able to, aggregate the information from journal entries. Right? It's able to say, this is what's year to date, this is what's one year ago, this is what's the average or, you know, the the count or whatever based on the journal entries in the query. The summary fields, again, look at the account as a whole. So close, but not the same. Aggregates work with journal entries specifically, and the summary fields work just with the account as a whole. And here you see, Cindy, now we have, you know, now this is broken up to the individual years. Could you do the same with lifetime received or no? So this one right here, this received total, is just received with no aggregate. So that is looking at my entirety of money that I gave to that specific fund. If I wanted to include, lifetime received, then, yes, that would show everything in the account. And then the summary fields also have that one year ago, year to date, two year ago, all of those. But that would be for the entirety of the, of the of the database or of the accounts, journal as a whole. So you can still include lifetime received. So, like, I could still come in here and say, okay. This is specifically for this fund or whatever, but now I also just wanna see beyond that what the lifetime received is. And we'll just run this again. And here, I still have the lifetime received here as well. So this received is the grand total for all the money that I gave to that specific fund. These aggregates are working with that fund. This lifetime received is looking at everything I gave total. And I can also come in here if I wanted to even go one step further and say, under summary fields, I could include year to date received total as well as well as, like, the one year, two year, three year, all of that stuff is in there as well. And it is giving me my one year ago received. So turns out that all of my gift from this year, all of my giving from year to date is to the same fund, the fund that we were already working with. But you could split it up to find out other, you know, like, oh, this is what I did for this specific fund. But I can also include in there what I gave as a grand total. That could give you some analytical information to say, well, he gives elsewhere. So it's good that he's still giving to something elsewhere, but, you know, maybe these are you know, maybe it'll help you identify some people that might be worth reaching out to to redirect some of the funding that they give elsewhere into the, into the correct fund that you want them to give to or something like that. Let's see here. Jessica asks this. I'm curious about how to build a report for all credit card journal entries and their fund type in between DBMS disbursements. So, Jessica, for that, it would start in the query. So let me go back to my so here, you can say, okay. Well, I wanna find all of the credit card. You might also want to include, like, maybe electronic funds transfer. You could also do that. You could create a query with this with the journal entry date, with whatever range you want that to be. You can also instead of the transaction gift types, you can go into journal here and you can find let's see here. It is transaction processor vehicle, and you can say, I wanna find everybody who's, you know, processed via the ecommerce page or, let's see here. Yeah. E commerce page should still pull up that. And then yeah. So you could use that, and I think also the virtual terminal would also pull up what you're wanting to to see. I'm not able to run this query, because of the I don't have, like, a BDMS or a processor connected to my database. But you could run a query with either the, transaction gift type from, commonly used fields, or you can go into journal and select the, processor vehicle. You can also use this processor too. Everybody should have at least one processor if you're using, BBMS, to process transactions, so you could use it this way as well. Then you put in your date range and then within your report, after you save that query, you can include oops. Jumped up there and deleted an extra line there. Let me put that back in. Let me put the, state province back in here. Afterwards, you can you can include all of the account information you want. Receive total. You can also put in the fund so you can see what fund they gave to. You can also come in here to journal fields. You can pull in the, let's see here. You can pull in the gift type. So that would say credit card or EFT depending on what, what you want that to show. As far as the gift type field, you can also pull in things like the, the credit card number, which will still be like x's and then show you the last four digits so that you have that information. But you could include all of this information into your report once you have the query set up with the date range. And one of those fields, whether it's the the gift types from the transaction gift types from commonly used fields or from the journal column or from the journal category rather, the processor or the, processor vehicle. Any one of those would would work to be able to find those credit card transactions, and that would give you something that you can at least try to line up with the disbursements as best as you possibly can. I believe that there is a KB that's out there as well that will tell you how to do that query and that report, to find those transactions that have the, you know, that that would align with the Blackbaud stuff. So, you can either search for that in the, KB, by going into the question mark icon and clicking on knowledge base, or, go to chat now and ask. And I would suspect that the chatbot would be able to find that, that link to that KB for you. Or, if you need to, you can ask to speak to a member of the team, and they can help you with that as well. Alright here. So we got Bailey asking, are you able to change the info to pull twenty twenty four report reports and make them into twenty twenty five reports, or does that need to be a new report? No. You can so, Bailey, that's one thing I I had kinda mentioned last week. Reports can be very generically named. Right? Because reports are relatively mindless. They they are shells just waiting for information to be fed into it. The query is what needs to be specific. So if you had a query, let's say, let's go into my Jeff transactions here. And let's say I had this named 2024 giving. And I and I come down here and the and the date range was, was set for 2024. Okay. Now for this, if you wanna make this into 2025, you can come in here, you can change the name of the query, and you can edit the dates from here. I typically say that it might be a good idea to build a new query with the same criteria just with a different date range just so that you have you always have a query because you never know when you might need that query again for last year's donations. You could absolutely do that. Now for the report, it really doesn't matter what the report's name is because when you get into the report, it's not looking at criteria. It's got these columns in here that are designed to basically have the information from the query filter into it and display into the report. So this account name or this received total, that's not specific to anything, like a query is. A query's criteria makes it specific and unique. A report is the most remarkable thing about a report is what it can is how you can kind of use, like, these kind of the various different, grouping options, the various different aggregate options, the various different fields that allow for you to, display the information. It's unremarkable in the sense that it has no criteria. It's just waiting for a query to be selected when you click save and run. So at this point, this is what gives the report its identity is the information from the from the query. So, so that is where, you know, you don't have to necessarily create a brand new report. You might need to create a new query. And one of the things I said last week was that, you know, you may build 20 times as many queries as you will ever build reports because the queries are what are unique and special and finds the exact information that will later be displayed on the report. So, so, yes, you may have to build a new query for the date range to be the new, you know, whatever year you want it to be, whether it's, you know, changing it from 2024 to 2025. But the report can be the exact same report. Oftentimes, if I'm kind of coaching somebody, through, like, okay. Are you going to be using a lot of different types of reports or if you are you building a lot of different queries? I tend to coach them to be pretty generic when it comes to the, to the report's name. Just calling it giving report or, annual giving report or year over year giving or whatever the case is. It's not saddling it with a specific date range or a specific year or a specific definition. The query should, but the report stays generic. And that's, so, yes, you may have to create a bunch of queries from time to time, but you may, year over year over year, just filter it through the same, you know, whatever year that the query represents. It's just going into the same report you've always used. So, yeah. So the next question here comes up, and, yes, I did, accidentally read that as Sugar Ray originally. Sorry. But, if you have time, are you able to show how you would pull a report of all constituents in the database for the previous year, whether they have given or not? That's a great question. Yeah. Yeah. I and trust me, as somebody who's got, Jeff spelled with a g, as common as it might be in Australia or, or Europe or, well, particularly in, England and and, Scotland, You'd be surprised what I hear a lot too. So, yes. So with, with this, this is actually an excellent question because this is something that does not come up too often, but could be very useful. It comes up, most of the time whenever I get asked a question very similar to that is that it is sometimes used in audits or and sometimes used in some way to, maybe not necessarily an audit, but an audit for a grant proposal to say this is these are the number of accounts that we had up to this point. And these this is the outreach that we have, or this is the reach that we have in general. Now the way this would be done, I I mean and in terms of I guess I can start with the report because the report is going to be really, really simple because the report is only really going to pull, like, account information like this. So you might include some of the summary fields like lifetime received total, and so forth. But the report is going to be extremely simplistic. Account information, whatever other fields you might want to pull from the user defined fields, account section, any kind of summary fields you might want to pull in. But the query is, this is where things are are a little bit more interesting because down here let me take this out so we're looking as if it's like a brand new normal query. Our data return type is going to be accounts because, again, we want the accounts even if they have never given, meaning they may not have any journal entries. So we definitely don't want data return type to be journal entries. We want it to be accounts. Up here under starting query we want it to be set to base all constituents. But down here, there is a category of fields called dates. And down here, we have, the very first thing listed is account created date. What I would say is leave the start date empty and only put in the end date for the for up to the year that you want. So in this case, it'll be '12 thirty one twenty twenty four. What this will do then, if I preview this, is this is gonna show me all of the accounts that I had in the database up to this point. Right? So I had a 144 a 148 accounts at the 2024. And I can also prove that by going in to let's just pull in here the a b c organization. When I come down here, oop. Nope. I gotta go to the account settings. You'll see here that this was created on 07/25/2023. So they would have been in the database. Now they may not have any journal entries. They may not have any, giving, which they don't, but they are in the database. So the field here that we wanna use is we wanna come in here to dates. And the very first thing listed under the drop down menu is account created date. That's the only piece of criteria you need. You can then come over here to reports, and when you like I said, the report can be very simplistic. You can have Now the one thing you can't include would be specific journal entries, but you could include some of these summary fields like how much they've given, what's their transaction count, all of that sort of stuff. And you can include whatever other account fields you want. And when you save and run, you will have your report that will indicate how many people you had. And maybe some of this you know, maybe including something like lifetime, received total would be helpful for that grant purposes as well. But that's, but the query is going to be very simple. It's just gonna be that one piece of criteria. Hopefully, that, oh, but if I, choose lifetime received total, it will still include those who have not given credit. Yes. That is absolutely correct. As you'll see here under lifetime received total, ABC organization, Angela Adams, they both have zero, but Barry Allen has $15,002.90. Alright. Deborah asked, is there a way oh, yeah. You're very welcome. Very welcome on that. That that's a that's a good question because that does come up not often, but enough to where yeah. I mean, it it is good to know that you have that information there as far as finding out when an account was created because that will also help you understand how many accounts you had at a certain particular date. There's also another field in there about, like, last time they were modified. Sometimes that can be of assistance if you are wanting to check and see maybe if a user had modified something about an you know, you can kind of maybe have some evidence around, like, oh, this is where some stuff got messed up in the database. But the most common one is the account created date. That can also be included in the report as well. The account created date will be found under account fields, and it has the account created date as an option. Yeah. And, Cindy, that's an excellent, yeah. The API data transfers, that's an excellent time to use modified. Yes. Absolutely. Because if you're doing, like, mass updates, if you're doing imports, if you're doing API type stuff like that, yes. The modified can be handy in those types of tracking down what has happened or or what might you know, what accounts might have been touched in certain circumstances. Yeah. Same thing can happen with the journal entries. There is also a journal entry create a date as well. So those are things you can also use to find out when certain things were added to the system as well. Alright. So Deborah asked, is there a way to enable queries or reports so that they do not show up on your list? Or do you just need to delete them? So unlike with, user defined fields, there are not yeah. Disable. Yeah. I'm sorry. I I read it initially as disabled, and then when I read it out loud, I said enabled. Yes. So unlike with user defined fields because user defined fields, the reason why you can only disable those instead of deleting them is because the system, while in some ways very smart. Right? Like, it knows when something has been modified. It knows when something has been added. It knows how to pull certain information or display it into a report. When it comes to user defined fields, once you save a user defined field, the system at that point just thinks it's part of itself. It doesn't really know if it's being used or not. So to prevent loss of data, it just plays dumb and says, yeah, you can't delete it. I don't know. I don't know if it's in use. So and the same thing goes with, like, funds campaigns approaches. Right? But with queries and reports and communication templates, there is not a disabled or hide feature. It's just it it's either it's there or you delete it to get rid of it. Now one thing that I would recommend, if you think that, I don't really wanna see this, but I don't really know if it's still in use, or I only use this, like, once a year or twice a year or something like that, then what I would probably do instead is create a new category for the and call it something like unused queries or, randomly used queries or something like that. And then once you save it, you could come in here, like, bay my base category is a good example because I have 56 queries in here. But you can come in here and then you can say, okay. Now I'm gonna move this to a different category. And once it moves it, it will get out of the way of your most used categories and placed into a randomly used or rarely used category. And then later, if you realize you know, because here, not only can you see when it was created, it will also say when the last time it was used for a report or for a, a communication. At that point, you could say, okay. Well, I haven't used this in five years or whatever. I can delete it and move on. Yeah. And, you know, you you pointed out, an excellent point there, you know, is that especially if you inherit databases that are, you know, five, ten, fifteen years old. There are some people who use eTapsley and have used it for twenty years. You know, you could have so many queries and reports built up in that that you don't really know what's been used, who created it, or you don't have any idea if the person who did create it created it by mistake or it turned out not to get what they wanted. They talked to support. They got the steps that they really needed to to make that query work the way they wanted to. So, you know, you could you could stash it into another category. And you can always make sure that the cat because, you know, you see the little cross of arrows here. That means you can move things around within categories, and you can also move the categories themselves around. So you can always make sure that it shows up at the bottom, kind of out of the way. And then you could go back in and and review later. It's like, yeah. We never used any of these for any significant reason. So then you can delete it at that point. The only time you need to be worried about deleting queries in particular this is not an issue with reports. But with queries in particular, the main thing you gotta be worried about when you click delete is whether or not it is being used as, a piece of a compound query or as the starting query in another query. It doesn't let you remove a block from the, the the the, dependency of of another query. Reports, you just delete them. But, and, you know, again, with reports, the more you get used to reports, the more you will realize the less, you know, the less you really need to worry about creating a bunch of extra reports. Like I said, again, that kinda goes back to that idea of reports being more generically named and generically built. So yeah. I mean, you might get it. You you know, some people I have seen or I've I've talked to some people who've been very efficient with reporting to the point where it's like they have a category for their, you know, for their mailing reports. They have a category for their account reports. They have a category for their journal entry reports or their year over year reports or whatever. And it's just, you know, each category only has, like, three or four or five reports in them. And the only thing that differentiates them is the the the details around, like, the grouping or what, you know, what exact fields are selected for that particular report and how that's put together. So so yeah. Yeah. Is there a way to easily delete queries folder? So each so once you have moved so, like, the only way you can delete a a category of queries is if the category is empty. So here, like, let's say I wanted to try to delete this event queries. You can't, you can't do that because there are two queries inside that. So once I have either moved these queries out of this category or I deleted them, We'll just delete these. Now when it says zero, I can come in here and I can say, yes. Delete that, and then it's gone. So that's something else to keep in mind. You can't delete categories, unless the queries have been either deleted or moved away. So but, Raima, thanks for for bringing that up because that is that is a good point. Yeah. So, Raima, yeah, you're you're one of those examples. Like, I mean, I I know I talked to Raima a few times back in my support days. That was over well, that's almost ten years ago now that I've been in support. So, yeah, I mean, that's an example a perfect example there where, you know, she goes back to the early days of ETAP, and, yeah, there's going that's going to naturally build up a bunch of extra queries and reports, and that's yeah. Sometimes that just has to be managed or moved into a category to deal with later or, the LEAP ones you know you haven't used in a long time. Alright. So we are about yeah. So we are about fifteen minutes here left to go. Are there any other questions that people have? Let me scroll up also to make sure I didn't miss anything here. Nope. I didn't. Okay. Don't see anything missing there. I'm trying to think if there was anything that I also wanted to, oh, you're very welcome, George. Thank you. I cannot remember. Is there the, is there a best place to see how to run certain reports as reference? Yes. So again, that would be an excellent use of the knowledge base here. So when you come into the knowledge base, this little thing will pop up here. Let me just see what happens if I put in report, and I can select to pull eTapestry. So here's an information about grouping reports. So that's one thing you could do there. What's the difference between a query and a report? That's really good for, people who don't really have a whole lot of experience with queries and reports. How to create an email list using a report? That's gonna be a step by step, guide here. So if I were to click on that, you'll see that. So that would be a good place to start. I typically, the more information you add to the question. So, like, so, like, you know, report for giving in a year. So how to build a a query report to compare giving from one year to next. So this will also provide you with the steps on how to do the query and then the report, and it will you know, this uses the summary fields option. So that's a that's a good one to use. How to build a report and query, that shows a donor's giving total for each year. So that's, yeah. So that's, you know, the the knowledge base would be a great place to start as far as that goes. Another thing to take into consideration when you go into the reports here, you also have this little orange, box here for report tips. And, you know, this also gives you, like, some how to, like, how to create a custom report, how to create a, or how to run a standard report and so forth. When you actually go into create a new report, there's this building a popular report, and it will give you some, specific reports that you could take a look at as well. So these are also all knowledge based articles as well. Deborah asked here off report subject, when running the NCOA check, I'm worried about the wrong things getting changed. Is there a way to make it happen with a backup of current database? So what will happen when you so you're talking about coming in here just for everybody's reference here, coming into management, clicking on the address finder NCOA. Now when you run this, it does automatically make those updates. Now what it is basing it on is it is based specifically on the information that matches or is able to be found, in the USPS's database of addresses. So it's not it it should not affect deliverability. But, and it won't and it should not change anything about the the person's name. It's gonna just update the address information. But if you are concerned about that, one thing that will happen is that it will create a note entry in the journal entry, and it will explain what was changed. And it will show the older information in there for your records. So conceivably, you could set up a query and a report of, like, note entries and what the notes say after you complete a, after you complete an NCOA address finder run. So that would be one way that you could kind of, you know, mitigate that and just find out. It's like, okay. This stuff looks good, but let me make sure and you can run over, like, oh, okay. This information got updated. This information got, and this information needs to be edited again or whatever the case is. So that that would be one way to do that. The thing is is that we don't do the, NCOA with with a manual process primarily because the the key reason is we don't want to have to add the extra step of doing an import and update from an import. Importing, a little bit more complicated. We want the address finder to be a little bit more seamless. And it it does require the it does require the trust in the the postal services database. Now if you're in Canada, it's done for you through our services team. So Canada's, NCOA process works a little bit different, because it doesn't have quite the same thing there. Does it take into consideration winter summer addresses? It should. I've never heard of an instance where somebody said that something got changed because of a vacation address or a snowbird address. My impression is and my, my history with it is is that it has never affected secondary addresses like that. The idea is is because you you do have the you know, you you do tell it to own my recommendation would be to always look at the primary persona. And the primary persona will be the one that is worked with. So whatever their primary one is should be the one that that works. Let's see. Is building a re a relationship report a different a different than a typical report? Yeah. So a relationship report, it it what it will do is it will based on a specific relationship, it will show you, like, who has that relationship. It only works with account information. It does not pull in any journal entry information. But it does, so it it lines it up to where it says, okay, on the on the left hand side, we're gonna have, husband. On the right hand side, we're gonna have wife. And then it it shows who has those relationships and and, what those relationships are. So it is a little bit different. Definitely worth taking a look at at that, KB article for sure. That's about that in that, in the report tips section there. Alright. So I think we are about at the end here. So let me pull up my slides. There we go. And, again, Blackbaud View, that's a great place. There's a there should be some training in there about reporting as well. Specifically, you have a if you have a, learn more subscription, there should be a, instructor led course that talks about queries and reports as well. That would be a good one for you to check out. Customer support knowledge base, I tend to talk about as one because oftentimes when customer support is engaged, they will refer you to knowledge base articles because those will have the steps, for what it is that you're asking about. And it also helps them with, finding out if, you know, what the answer is to your question. But, you can certainly get in, in touch with support by using the question mark icon, clicking chat now. That does start with the chatbot, but you should be able to, if you don't get the information that you want from the chatbot, be able to connect to a, support member who can then, take a look at the more, detailed information about your question and then direct you in the right, in the right direction from there. Of course, the Blackbaud community, also a great place to go to. I definitely recommend that people, get involved in there because it's a great way to connect with your peers, to, you know, ask questions amongst the peers, kind of find out what some other people might be doing in certain circumstances. I know sometimes we've had, webinars where people have kind of given some advice or some information about some of the things that they have done, based on the the questions that were asked within, the chat of the session. But the community is also available to you for a very similar purpose. We also have, these programs that I often talk about at the end of all of our sessions. We have the Blackbaud Champions. I like to think of that a little bit like a community plus in the sense that, you can connect with other, users of Blackbaud products. But what's different is about the champions, you will be invited to opportunities to provide feedback to Blackbaud directly. Also, there's, there are some, professional development opportunities that are involved in there as well. It goes beyond what you're actually utilizing, whether it's eTapestry or or any of the other Blackbaud products. So it's a little bit more product agnostic as we as we would call it. But then there's also a little bit of a gamified rewards program in there as well. Then we also have our reference program. That's where you can connect with, somebody who might be, thinking about, purchasing eTapestry. You have total control over how often somebody is willing to take a call, but it is a way for you to share some of the, things that you have done with, with eTapestry as well as, you know, some of the areas that, eTapestry has helped you be more successful as well. And then we have the spotlight your success. Always open for people to, want to join in on a webinar with me to talk about some of the things that they do inside their database. Or if maybe not doing a webinar is, is, you know, you prefer not to do a webinar, You could also always, write a blog post or something like that, kind of detailing some of the the things that you like to do inside of eTapestry that helps you be more successful and helps your organization achieve their, goals and your, mission. So something else to take into consideration, if you're ever interested in anything like that, you know, you're more than welcome to reach out, in the chat during one of these sessions, and we'll be happy to, add you to the list of people to reach out to and and talk to about these programs. Alright. So thank you so much for attending. I believe next month, we're going to be talking about accounts, I think. I'm trying to remember here. Let me see if I can pull up the, the actual list here while we still have a couple of minutes. Sorry about that. I accidentally clicked sorry about that. I accidentally clicked off my, my entire thing there. So let me go back to here. And let me pull this up instead. Sorry about that, everybody. I did completely and totally, left the, the webinar there for a second. This was what I meant to go to here. Yes. So I believe we are yes. So we are talking about, account tax month. So this came from a this was actually a suggestion from, another listener here that was, that that talked about, like, you know, maybe getting into a little bit more information about what is actually stored in accounts, because that is something that is as basic as it sounds, is something that people could use a little bit of a refresher about, like, why is it important for certain things to be stored in certain places within an account, what are all of the things you can do with an account, and so forth. So that is definitely something that, I wanted to include on there. And then in October, I'm going to talk about one of my favorite topics, which is talking about journal entry contacts in particular. So, I look forward to seeing you there, and, hope you all have a great rest of your, great rest of your day, great rest of your week. And, I look forward to seeing you all in next month's sessions. Thank you, Cindy. Thank you, everybody. You're certainly welcome. And, like I said, have a great rest of your day and a great rest of your week.