nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Teamraiser - Bring Back a Team from more than one event-year ago

Jeffrey Kaplan

While managing a Teamraiser event on the admin side, you are able to edit a team's details and associate that team with a team from not just the previous event but previous events spanning multiple years (following the chain of “previous event” selections through the years of events).

Is there a way to allow a participant to bring back a team (during registration) from an event further down the chain than the directly preceding event?

Our use-case is, with the weird year of 2020/21 and covid, it would be nice to allow users who may have lapsed during this time the ability to bring back teams from 2019. Using s-tags or an API call we can track those previous registrations and prompt the user during registration, but we cant get the link to work for the “bring back this team” button for teams from events more than 1 event-year back.

The format for the URL to bring back a team is
https://…/site/TRR?pg=tfind&fr_id=0000&fr_treform=00000&skip_login_page=true

We tried just plugging in the lapsed team ID to this url to test and received an error, though the error appears unrelated ("the participant must be a team captain to bring back that team" -- oddly, the participant I tested it on was the team captain, so I'm not sure why that error is appearing).

Please let me know if you have done this successfully or have any ideas on how to implement!

Find more posts tagged with

LuminateOnline

Comments

Kenneth Keil

Jeffrey Kaplan:
While managing a Teamraiser event on the admin side, you are able to edit a team's details and associate that team with a team from not just the previous event but previous events spanning multiple years (following the chain of “previous event” selections through the years of events).
Is there a way to allow a participant to bring back a team (during registration) from an event further down the chain than the directly preceding event?
Our use-case is, with the weird year of 2020/21 and covid, it would be nice to allow users who may have lapsed during this time the ability to bring back teams from 2019. Using s-tags or an API call we can track those previous registrations and prompt the user during registration, but we cant get the link to work for the “bring back this team” button for teams from events more than 1 event-year back.
The format for the URL to bring back a team is
https://…/site/TRR?pg=tfind&fr_id=0000&fr_treform=00000&skip_login_page=true
We tried just plugging in the lapsed team ID to this url to test and received an error, though the error appears unrelated ("the participant must be a team captain to bring back that team" -- oddly, the participant I tested it on was the team captain, so I'm not sure why that error is appearing).
Please let me know if you have done this successfully or have any ideas on how to implement!

Hi @Jeffrey Kaplan !

Thinking this through the only idea I have would be to fudge the data in to the system as though you held the 2020 event and the teams you are interested in attended.

It wouldnt be ideal, but, you would be able to get the effect you are looking for.

What I would think could be a possible solution is to create a registrations report for your 2019 event to gather the details on the participants and teams you'd need, and then do a registration import to just import everyone as free registrants, in the same teams they were for the 2019 event for the year that was missed.

You could potentially setup a new “Covid Pandemic / Unable to Attend" participation type to import them as where the registration fee is $0 so that you'd be able to register them free, and segment them apart from anyone that may have registered for your 2020 event (if you held limited registrations or anything like that).

Then, you'd have the data in the system that'll allow you to have teams return even though the Covid pandemic prevented you from actually holding the event last year.

For more information on TeamRaiser registration imports you can reference this documentation:

Richard Murphy

Full disclosure, I have not built this nor tried making it work all the way through but I did test out some parts of the process quickly to see how well they worked. It could require a full API build for both registration and looking up the previous events. I apologize in advance for the length of this post!

Step 1 ) Identifying the previous event IDs.
You can go back as far as you want but I've tested this 5 years back. Essentially, the idea is that you could use Noah Cooper's “Roll Your Own API” solution which is here on the forums. I tried to find a link to it but couldn't with a quick search. If I find the link I'll come back and update this post with it. That allows you to use a PageBuilder page to create your own API utilizing S-Tags which is the key here as I don't believe the API provides you with previous FR_ID data, though if I'm incorrect let me know.

Using that method you would send a parameter which would be the current FR_ID. With that you would start nesting E42 calls to get back previous years.

[[E42:[[S334:fr_id]]:prev-fr-id]] - Last Year
[[E42:[[E42:[[S334:fr_id]]:prev-fr-id]]:prev-fr-id]] - 2 Years Ago
[[E42:[[E42:[[E42:[[S334:fr_id]]:prev-fr-id]]:prev-fr-id]]:prev-fr-id]] - 3 Years Ago
…etc

Since the response using the “RYOAPI” method will be in JSON you would now have a list of FR_IDs going back as far as you need it. It's dynamic as you are passing the initial/current FR_ID to start the process.

Step 2) Using getTeamsByInfo to find the last event the user participated in
This is assuming you have made the user login before starting this process AND they are the team captain of the team they wish to bring back. I suppose there could be a method for non-team captains but I haven't thought through that.

In order to ensure the data you get back from getTeamsByInfo is the data you're looking for, you'll want to include a filter using list_filter_column=captain_cons_id and insert the current logged in user's cons_id as the list_filter_text. This will ensure you're only finding the user you want and that they were the captain of the team. Finding out what this column to filter by is truly trial and error. I wish Blackbaud would provide us a list of columns we can filter by. Sometimes they match the API response data, sometimes not. It's often a guessing game. If someone has a list of columns available for API methods, I will upvote all of your ideas on the LO ideas site as payment.

Personally, I would stop as soon as you found a result from a previous year (checking against totalNumberResults from the response data). Otherwise, I would iterate over each FR_ID you received from Step 1 displaying an error message if nothing was ever found after the entire process concludes which would mean the user didn't have a previous team.

Once you have found a previous team entry, you'll have a wealth of data about the team which can be used to process the registration via the API. You'll likely want to store that in a variable for use later on or pass it to the next function.

Step 3) Register the user via processRegistration
Here are the caveats. We're basically manipulating the system to let us “bring a team back” but we really aren't bringing a team back. We're registering a new team but we're able to access information about the previous registration to make it a quicker process. I suppose there are other methods you could use to store the data in the session and auto-fill the normal registration fields instead of using the API. If it were me, though, I would likely use the API.

Step 4) Bonus steps post registration (completely untested – thinking out loud)
Since we now have the old team information we could also attempt to bring back more information for that team including team photo (getTeamPhoto > uploadTeamPhoto), team page (getTeamPageInfo > updateTeamPageInfo) and team member data (getTeamRoster) which could then be used to possibly add contacts to the constituents address book. You could create a new Address Book Group (addAddressBookGroup) and potentially add that team roster to their list of contacts.

I have also used getTeamRoster in the past to give the user an option post registration (on confirmation) to send an email to all of their team members by clicking a button. This didn't require them to go into Participant Center to send it. The API method sendTafMessage allows you to pass in a comma separated list of email address and the content/envelope info for the message. I did something to the effect of “We're getting the band back together! Click here to join me again this year…”.

------

Again this is all mostly untested in the real world but I did test creating a list of FR_IDs and pulling the previous years team info in. Both worked. However, to the system this won't be a lapsed team returning. It'll just be a new team starting that year. I suppose it depends on what you're after. Data integrity or an easy way for participants to rejoin. As I mentioned there are probably ways to integrate some of what I've written to make the standard registration a bit easier by auto-filling in fields.

Even if this all seems like way too much to bite off, hopefully it sparked some ideas.

Best of luck!

Jeffrey Kaplan

Thanks for the thorough and thoughtful response Richard! We ended up using a similar approach to steps 1 through 3, using session variables to populate the normal registration fields rather than through the API.

I like the bonus ideas you came up with (step 4) to imitate the missing functionality of bringing back a team using API calls after the registration completes (this could be done on the thank you page). I was hoping there was some way to just hook in to the existing functionality of bringing back a team but this seems like a good manual way around the limitations.