In Part 1 – The Concept we talked about the vision and initial challenges we faced. This part we discuss our solutions to these problems, specifically around the Attendee Join.
In summary, we identified that we must use Teams Guest Access to invite Attendees to the conference for their privacy and our consistency. The solution was having a dedicated tenant built specifically for this purpose.
A Dedicated Auth Tenant
The solution for us was to stand up an additional Microsoft 365 tenant specifically for Attendee accounts. We called this the Auth tenant. Attendee’s knew this as RegforMe.
This would be used to provide every Attendee their own unique user account that would in turn be added to our Conference tenant as a Guest user.
To avoid confusion, we ensured that Microsoft Teams Exploratory Licensing was turned off on the tenant along with all other user initiated trial licensing so that no one in the Auth tenant could mistakenly turn on a service that would confuse everyone.
We also did not provision any Microsoft 365 service beyond Exchange Online which we needed for transactional e-mails. No user was licensed and no Microsoft 365 Apps showed in the Microsoft 365 Portal.
The Auth tenant gave us a level of consistency that we could build our registration onboarding automation process around, but also a single point of troubleshooting and ensuring people where properly added. If we spotted configuration mismatches they could be easily fixed on the fly.
Benefits To The Attendee
The benefits to the Attendee was that their corporate identity and privacy was protected from unauthorised people whilst participating in the Conference.
Attendees would see each other’s identity in the conference tenant as [email protected] and whilst Chat, Calling and Meeting Participation would work for them as Guests inside the Conference tenant, outside of it there was no chance that they could communicate.
This meant that Attendees could engage and communicate with anyone freely and without the threat of being hounded afterwards by unsolicited contacts.
Of course, with any event that has Sponsors there has to be some level of engagement, so receiving one email from each official Sponsor afterwards is a small sacrifice for attending an event for free. At least this way we could guarantee a level of safety to our Attendees that any follow-up communication received to their corporate identities was a legitimate approach by an official Sponsor of the event.
Once the conference was over, the Attendee could discard the account without worrying about leaving a footprint. Even after the event their contact card would be visible in Teams even in cases where their account had been removed as a guest. That was also a data security risk. Providing an Auth tenant gave us the ability to disable accounts following the conference without removing them from the conference tenant. Our thinking was that if we decided to adopt this model again, Attendees could use the same account once we had reactivated it.
Downsides To The Attendee
Although the Auth tenant solved a lot of technical challenges for us. It allowed us to invite an unlimited number of guests to a team without a license, gave the Attendee the privacy they needed and gave us a level of consistency we could wrap our registration automation around, it did present a challenge to Attendees. A challenge we were acutely aware of and anticipated, but otherwise unavoidable.
It meant that Attendees had to remember to login to Teams using that identity. Then once that challenge was overcome, the way that Teams behaves to an unlicensed account is an unnatural experience for those who are used to using Teams in their own tenant.
The biggest challenge was trying to communicate this to 2,500 people. Telling them not to sign in to portal.office.com and to sign in to Teams instead. Many expected the Teams app to show in the Microsoft 365 Portal. Of course it didn’t because the Auth tenant wasn’t licensed or activated for Teams by design.
Then whether through support direction or otherwise they sign into Teams and they do not read past the first line which says “You don’t have access to the Auth org in Teams“. They read that and assume that it’s broken. They do not see the drop down box directly underneath that had invitation to join as a Guest to Commsverse
This we knew was going to be our Achilles heel. We tried to limit the impact by raising awareness with our Attendees both in multiple e-mail, social activities, website sign-posting with blog and animated GIF. We even ran a pre-conference AMA 15 times before the event to raise this.
The Persistent Problem
Even after all this effort, when it came to it, several people had issues with following instructions. The simple fact is, people do not read e-mails and when it requires a call to action in the future, it gets filed and never found again. On day 1 we facilitated around 60 password resets due to forgotten credentials and 40 or so e-mails instructing them to click continue.
From the attendee perspective of course, this is seen as a poor joining experience. Frustrated because they now have to find some instructions and an account to login. But mainly because they haven’t taken the time before the conference to really prepare themselves for it.
It’s a downside of Online conferences is that people just do not treat them with the same respect and attention as in-person. They treat them as an online meeting. That means that the first time they are going to click a link to join will be when their Outlook calendar says meeting NOW! When they realise that they need to find credentials and log-in and already the session they wanted to watch is in-progress it build anxiety that can quickly turn into frustration and anger.
This isn’t a complaint from us about our Attendee’s behaviour towards the event, it’s acknowledgment that the enterprise online meeting paradigm has silently programmed us to be used to a one-click join experience and when that doesn’t happen it catches people by surprise and they panic.
We tried our best to weather this out for people and had support available for anyone who needed it. The majority connected fine without issues, some struggled. And a select few actually turned nasty, even without asking us for help. Taking to a chat thread to vent their frustration and emailing us in a four-lettered rant. Just because they couldn’t find their user account…
This actually surprised me. I knew there would be some friction with joining and had hoped that people could see through that for the wider picture and experience we were offering. I wasn’t at all prepared to be sworn at, especially in cases where the person with the issue hadn’t even attempted to get in touch to let us help them in the first instance.
Tying Registration To Auth
Now that we understood how we wanted people to join the conference at a tenant level, we needed to figure out how we are going to get an Attendee from our website, through registration, to having their dedicated account created, invited into the Conference tenant and added to the conference team.
Initially, we thought we would use a Microsoft Form from the Auth tenant to require name, email and other required information and use Power Automate to create the user account and then email it to the registrant.
However, our challenge was that at some-point we had to provide on-demand access to the video content post event to those who have paid for that access. If we where a completely free event, then Forms would have been ideal and it would have simplified the process for the Attendee. But we had to charge for on-demand access.
Not because we wanted to make money out of other people’s content, but because we were in a unique situation where we where committed to in-person with 90% of our turnover already paid out with no hope of refund and had the expense of setting up an online event which set us back in total around £7,000 with everything out of money we didn’t have. The only way to try and recover that was through charging for on-demand access.
But again, we encountered another challenge that we failed to overcome. The Attendee now had two accounts. One for the website and the other to access Teams. This created so much confusion for them. I totally got it, but it was a Chicken and Egg situation. I had to first get them to register in order to be able to create the auth account for Teams.
Using WordPress
Registration was never going to be simple for us. Not only did we have to get Attendees into Teams, but we also had to make sure that they had access to other resources in line with their ticket permissions e.g. on-demand.
So we had to widen our field of view to the long term goal of what we wanted to achieve. We needed an on-demand video hosting solution that would protect the content from being accessed by non-paying Attendees. Our search of the internet revealed lots of video hosting companies with paywalls built in. But this created yet another place for people to go and purchase / register etc. or another integration point that we would have to spend money and time, neither of which we had to develop. In the end, we decided Vimeo was the best solution for our video hosting. Why? because it allowed us to restrict embedding to a Domain and have private links to videos.
Vimeo wasn’t free, we had to pay for the Pro plan to give us enough upload bandwidth and storage for the content. An annual subscription was about £600.
But in doing this, it allowed us to focus on WordPress as the platform. This made perfect sense to us because we could centre the experience either side of the conference on one platform which combined Attendee registration, Content Access and our Website materials all in one place.
Creating Memberships / Tickets
We had a vision to create a membership rather than a ticket. Attendees would become a member of Commsverse rather than an Attendee of a single event. This allowed us a platform to build future relationships with Attendees and not be just an annual event.
We wanted to offer a new way to ‘subscribe’ to a conference. In doing so would grant access to premium content throughout the lifetime of the subscription.
Our thoughts where, we can offer a free membership that would give people lifetime access to any content or event that we decide to run in the future without having to register again.
An On-Demand membership that would grant access to video content not only from Commsverse 2020 but any other event we may run within 12 months of the start date of the membership. This meant that Attendees who purchased On-Demand access for 2020 by calendar, would also get the recordings from our 2021 March event without paying any more. Great Value.
Finally an All Access membership that gave them everything and one ticket to our in-person event each year.
Tied in with this we had to ensure that we could properly protect different parts of our website from unauthorised access. WordPress for a transaction based purpose is a great platform because it already has a well established marketplace for additional features or plugins. It meant, we could almost off the shelf purchase 90% of the functionality we needed. In a situation where time is of the essence, this was essential for us.
We settled for the membership plugin “Memberpress“. This is a premium only plugin with no free version, so we had to be sure it could do what we needed. Memberpress allows us to create different memberships and associate content access rules with each.
Initially we did start with a subscription membership. Trialling a new concept of “Attendee for life”. An annual payment guaranteeing access to whatever level you choose. We quickly realised that this was a bit premature for some. Whether that was down to us being an untested event or something alien to the normal expectations from a conference I don’t know. Anyway, we quickly moved back to a transaction based model whereby people could pay once and get time limited access. When that time expires, so will their access and they can choose at that moment to renew if they so wish.
Integrating with AzureAD
We had the bones of the registration sorted. We could provide the right access to the right people based on their membership to any web content on our website. Using Vimeo we can embed videos into protected pages etc. and design a portal experience for the Attendee to gravitate to.
In creating a membership, creates a WordPress account for that Attendee. The next challenge was how to use that information to create an account in our Auth tenant and let the registered Attendee know.
Initially, we thought about just exporting the users out of WordPress and running a PowerShell script every so often. But we quickly realised that this would be a huge admin undertaking as registrations grow. We needed a way to automate this.
Power Automate
Naturally we looked at what Power Automate could do for us. Although it did not offer out of the box integration with MemberPress or even WordPress, it did offer everything else we needed to create a user account and inform the Attendee.
A premium feature of Power Automate is a trigger on HTTP request received. Premium features come at a price of about £15 per user per month. However, we timed it right to utilise our free trial of this instead.
The trigger gave us a HTTP endpoint that we could send some post data to from an external source that we could then use inside our automation to create the user account.
From WordPress we where interested in the following information from each Attendee
- Their first and last name
- Their business e-mail address
We created our own action in WordPress that triggered each time someone registered for a membership using our Memberpress sign up form. This action sent the above details to the HTTP endpoint in Power Automate as a JSON array.
Once we received this data from the website, the flow can begin. The first step was to create a random password. We did this as a variable and using a prefix with a substring generated from the current timestamp of the request using the below expression
substring(utcNow(),20,8)
Next we needed to create a two digit random number that would be appended to the username to account for people with the same first and last name. Again this was another string variable using expression
rand(10,99)
Once we had that information stored, we could now create the user account. Before we do however, it is important to account for how people enter the form data and any special characters that aren’t conducive to AzureAD UPNs.
In our custom WordPress function, we applied a filter to replace umlauts with ‘oe’ and other accents as well as apostrophes for the O’Connors of this world. Beyond this people will invariably type whitespace after their name. You can remove it as part of the WordPress function or do this in Power Automate. We did it in Power Automate because this was a fix we had to apply retrospectively.
Creating a user in AzureAD using Power Automate is easy. Use the built in function and pass in the values
At this point we needed to pass a response back to WordPress as it was waiting to receive the user account created in AzureAD. The creation of the account is fast, what happens afterwards takes longer than the web server will wait for a response to a REST call.
Why did we need to send a response? Well, we had a custom meta field that was populated for each Attendee that displayed the user account created for them. This was visible in the Attendee Portal of the website when they signed in. They could even reset the password if they wanted to.
The Response is an action, part of the premium HTTP trigger. We set this to 201 and supplied a JSON payload containing the username and the email address of the registered user. The email address was used as the unique identifier in WordPress
Once created, we then used the Send E-mail action from the Outlook integration in Power Automate to send an e-mail to the registered user containing their auth account details.
So right now the Attendee had a valid account in AzureAD created automatically at the point of registration and they are e-mailed the details. The account is written back to WordPress and accessible in the Attendee Portal.
The next piece is inviting this Auth account into the conference team as a guest.
Part 3 – Inviting the Guest to the Conference.
