 Thank you, everyone. Hola a todos. Hello, my name is Helen, and good day. So I'm from Catalyst IT, Australian team, obviously based in Australia. And if you haven't already noticed, based on the title of the abstract, there's quite a lot of words here. So it's probably good that I'm starting here early and I'll try and get through it quick. I might need to do a bit of a cracking pace and there may not be that much in it, so you have been warned. I'll try and keep it at a reasonable pace. Lots of celebrations in the hall. So who am I? I'm James Williams. I'm a senior technical manager at Catalyst IT. I have a background in hydrocation, mainly tertiary institutions and universities. So that will be seen in some of my basic assumptions around what the integrations I'll be talking about. Although as education landscapes are changing, a lot of the ideas around use and rollments, use of vacation rollments and integrations is moving more to sort of smaller short course and micro-gradential teachings, which means that I'm sort of also trying to make this applicable to smaller organisations and people who are maybe even just starting to use Moodle for some of this. So that's the direction I'll be taking. It might start from a large university focus, but it will come back hopefully down to a small level and then I'll expand again for some ideas. So I'm going to aim with a simple beginning, provide a bit of a high level breakdown about students, teachers and admins do. I'll take a quick drive past some of the complexity, hopefully that getting sucked in to the complexity, and then I will bring the focus back to basics around smaller cohorts. I'll try and get some dots between some of the Moodle components and how they fit together and walk through some of the integration options, plugins and challenges, pros and cons, and then hopefully just show you a couple of a list of options, a list of plugins, resources you can use for getting yourself up to speed and where you can look for more help on that journey. So I suppose to start with what we already know, and know is dubious here. Learn enrolment processing is or was painful for some of us? Maybe it is, maybe it isn't. Third party systems integration is difficult, it's a time between to build, often both, maybe it is, maybe it isn't. Certainly getting better as tools evolve. But the applications or the implementations to give a different meaning can differ due to different types of users, such as authentication types, different types of courses, such as whether you plan to have one Moodle course with content that you reuse with different student cohorts coming in and out of the same course, or whether you roll over that Moodle course to multiple copies of that course with the same content and different cohorts coming in and out of those cohorts. And of course there are different ways of getting students into those courses, different enrollment plugins and methods to enroll them and obviously the integrations to automate that moving forward. Excuse me. So a simple beginning. The student journey, sorry, not again, no very, very high level, I'm not going to talk about student journey, but obviously you've got enrollment and payment. You get access to the course. They learn and study through the course to build their skills. They demonstrate their intended learning outcomes through assessment, usually. And then they obtain confirmation or credit to progress the next course or complete their short course with some kind of credit to the institution and or certificate of some kind to demonstrate that. The teacher's story, we can't forget about them. Very important. And their journey starts before the student usually with course design and course approval processes. Content creation, sometimes these are all mixed in together. Then teaching, more teaching and then marking and more marking and marking and yet more marking depending on whether you're leveraging some of the fantastic quiz and question functionality in middle 4.0. Thank you so far. And Nathan and all the other contributors from those projects. And then obviously admin, admin, admin, admin and more admin which unfortunately tends to be increasing for some of the educators. That's rather an unfortunate trend that I've certainly seen and heard about. Then the life of an admin as we slip into very loose terminology here. Could be a user, could be an admin staff, could be an integration admin system. But just generally you've got the course list, a website or contact information, might be a handbook system or you have staff that receive calls, emails or web contacts or form submissions and payment. If it's not through an automated system, you've got the creation of the courses themselves, the enrollment of students in the courses, publishing student grades, ratifying student progression, completion and graduation through the system. Adding a dash of complexity, maybe stirring it a bit of a sprinkle, maybe a bit too much. Manual user enrollment management for these things in small organizations or large organizations tends to be, well, we'll just upload a CSV. We'll just stock that solution in the short term, then we'll improve it. It's not scalable. If you're doing a good job, if you've got content that enrolls people that you're trying to scale up or you've got a new offering, if that's good, that success comes with growth. And growth comes with edge cases and probability that there are going to be manual issues you have to work around and it very, very quickly outstrips your staffing. Change of user details, late enrollments, early enrollments, ID updates, even if you put deadlines around census dates, for example, and many universities cannot enroll after census date, it still happens. Can't enroll, it still happens because they're always even fixes in the system where system integration went wrong or something went wrong, just has to fix. It's not correct, it's correct, the record. So you think about automatic user enrollment management and user creation. It's still tricky. Larger organizations with more infrastructure might manage user accounts with just a single database, multiple databases, integrations of the LDAP or SAML single sign-on or OpenID Connect, which is growing in popularity more and more in recent years. But they bring in other questions around creating the accounts on the fly when they log in or pre-creating the accounts. Do you want to synchronize them in batch or have them come in being pushed in, being pulled in? And the reality is they may actually exist in batch jobs and coexist with just-in-time user provisioning and creation or instant web service and API account creation. And timing can be a bit of a thing there. So sometimes making sure that the account exists, the bulk synchronization has happened, the user can log in. It can be tricky because batch jobs take time to drop, take time to run, and just-in-time provisioning or APIs are instantaneous in real-time. Can the user log in and be created on the fly or not? Can they log in before their accounts are created? It doesn't matter. It depends on your scenario and your individual requirements in many cases. But it can have impacts if you've got downstream integration of a system such as OpenID Connect or you've got other systems using Moodle as your source of truth or your next hop if you haven't got middleware, buses, and so on to manage those things at an institutional level. Coming right back to some components and options that are in Moodle just to get people thinking about this because as soon as you talk about integration at a larger scale or you're talking about the possibilities with newer clients and newer people, it's very hard to think, oh, I've got authentication, can I log in, but do I have an account and am I rolled? So I just break it down very, very basic level. You've got authentication, you've got enrollment. User accounts can exist with an authentication type, being a core Moodle plug-in or a third-party plug-in. And having account might let you log into Moodle, but not necessarily a course. And enrollment is obviously enrolling that user account into the course where the content, other participants, and commissions for those roles and capabilities. I'm not sure if that is very visible there, but that's just a quick list of the core authentication methods and plug-ins in Moodle. Manual authentication, having users pass inside the database through to LDAP integration with LDAP servers or LTI authentication allowing Moodle to act as a tool provider and have accounts created. And then so many more settings there can very quickly come out of hand. And we've got enrollment plug-ins, again, mainly core. You'll see some crossover here in terms of enrolling students into courses, self-enrollment, similar to self-registration, and create the account and then self-enroll into the course itself, or synchronization. PayPal is an interesting one there, but I'm just going to move on. Then obviously single sign-on and SAML, OpenID Connect, it's become ubiquitous now. It's not very new to many people. Some people might be getting it going, but these are the two main players that we talk about. I do a shameless plug with the All For SAML 2 plug-in and Catalyst's name on there that everyone knows about, but it's a contribution to the community and it's great to see people always putting bug fixes and things in. It's great to really build on everyone else's work and keep those things going. And then there are web service APIs. This is a screenshot actually from inside Moodle, just in the web service API documentation. You may even have custom web services already installed in your Moodle. And there's just some relevant ones for core user APIs that you have access to or enrollment web service APIs for managing enrollments or getting enrollment user information and classification. And as I said before, being able to authenticate doesn't guarantee you can log in. So you may want to prevent, just in time, provisioning a user for various reasons and rely on batch synchronization for the accounts to be created, such as Moodle integrated with LDAP or single sign-on even might allow user to authenticate, but then knock them back because they actually don't have an account in Moodle. It's usually not a problem because due to timing in your favor, there's distance in the student journey between a user's payment enrollment, the account getting created, them getting enrolled into a course and all them trying to access Moodle, they've usually got an account in there, so it doesn't matter. But it depends on various reasons, sometimes good reasons, sometimes bad reasons, but they're all reasons and they all applicable to you and your institution. But they can have implications further downstream with, as I mentioned before, other integrations with Moodle or server-party services with the account exists, when does it exist and so on. It doesn't need to be thought through there. But don't be intimidated. You got this, okay? These are big questions, they're big topics and they seem very nebulous and I hate to think that I've added to that just now, but the reality is that coming to Moodle green fields or existing installations, whether it's a migration to Moodle, rebuilding platforms or building for existing infrastructure, it's all achievable. The Moodle docs are fantastic due to the contributions from the community, all of the building work on the plugins and the way we can get these things happening. There's some really great advice around here for managing a Moodle site, how to make these things fit together. I strongly recommend you go look in the Moodle plugin directory, particularly around authentication and enrollment as they work hand in hand, particularly in the LTI space. And even your own Moodle site, as I mentioned earlier, you may have your own custom APIs built in, maybe built by the previous administrator, maybe the knowledge is lost in your institution going back years and years, go and have a look. And this is even just a subset. But don't panic. The strategy for success is to read the docs, not to panic, to think carefully about your environment, break down your requirements, explore your configurations, and remember your tool sets. There's plenty of options for configuring and tailoring your Moodle instance to your unique requirements or keeping it simple if you've got those opportunities. Community engagement is key, ask in the forums, build it yourself or find a partner. Thank you.