Listen

All Episodes

Managing Multiple Devices and Users Within PRODA (and RAM)

In this episode of Understanding the NDIS Related Portals, Winter and Will unpack how to manage multiple staff and software systems safely across PRODA, myID and the Relationship Authorisation Manager (RAM) as your NDIS business grows.

They start by clarifying what PRODA, myID and RAM each do following the late-2025 transition away from PRODA logins for most NDIS portals. You’ll hear clear examples of which tasks run through the NDIS Commission Portal vs myplace and other operational portals, and why this distinction really matters once you move beyond a sole trader setup.

Next, they step through a practical, role-based approach to onboarding staff: from helping a new team member create their personal myID, to sending and accepting RAM authorisations, and understanding PRODA attribute types like service-user, member-management, device-management and service-link. You’ll learn how to design simple “access levels by role” for support workers, admin and finance staff, compliance managers, IT and practice managers, and owners/directors.

Finally, Winter and Will explain B2B devices and how they let your client management software talk directly to government services without someone logging in each time. They outline who should manage devices, how to register, activate and extend them, and how to build a basic security checklist covering RAM authorisations, PRODA memberships and B2B devices. The episode closes with a clear offboarding process so former staff lose access promptly while your audit trail stays clean and compliant.

If you’re a newer NDIS provider or just starting to scale beyond yourself, this episode will help you turn PRODA and RAM from a confusing patchwork into a simple, secure framework that grows with your business.

This show was created with Jellypod, the AI Podcast Studio. Create your own podcast with Jellypod today.

Is this your podcast and want to remove this banner? Click here.


Chapter 1

PRODA vs RAM and myID – Getting the Foundations Right

Winter, EnableUs Community

Welcome back everyone. Today we’re diving into something very un‑sexy but absolutely mission‑critical if you’re an NDIS provider: how PRODA, myID, and RAM all fit together now that the rules have shifted.

Will, EnableUs Community

Yeah, and if you’re listening going, “I thought it was all just PRODA logins and that weird SMS code,” you’re not alone. The big change is that since November 2025, day‑to‑day access for things like myplace isn’t managed through PRODA anymore, it’s managed through RAM – the Relationship Authorisation Manager – using people’s personal myID.

Winter, EnableUs Community

Exactly. So let’s lay the foundations. Think of it like this: PRODA and RAM are two different tools, and myID is the digital identity that plugs into RAM. PRODA now mainly sits on the Commission side of things – Commission Portal, registration, incident reporting, audits, all that compliance gear. RAM plus myID is what controls who can get into myplace and the other operational portals you use every single day.

Will, EnableUs Community

So if someone on your team is doing provider registration, handling incident reports, or coordinating audits with the NDIS Commission Portal, their access flows through PRODA. They need a PRODA account and to be added as a member of your organisation in PRODA.

Winter, EnableUs Community

And if they’re doing payment claims, service bookings, managing participant relationships in myplace – all the operational stuff – their access is authorised in RAM using their personal myID. Not a work email, not a shared login, but their own myID that follows them even if they change jobs later.

Will, EnableUs Community

Yeah, and that’s where a lot of providers trip up when they grow. As a sole trader, it’s just you. You’ve got one PRODA, maybe now one myID, you hop into whatever portal you need and off you go. It feels messy but it kind of works.

Winter, EnableUs Community

But once you start hiring, that falls apart really fast. So picture this: you’ve grown from just you to three admin staff doing claims, two managers handling audits and compliance, and client management software that talks directly to NDIS systems. Suddenly you’ve got people and software all needing access in different ways.

Will, EnableUs Community

In that scenario, your admin staff don’t need to be touching the Commission Portal. They mainly need myplace access through RAM, authorised to your business using their personal myID. Your compliance managers probably need both – myplace through RAM and Commission Portal through PRODA – because they’re across both operations and registration.

Winter, EnableUs Community

And then your software is a whole other thing again. It doesn’t log in like a person. It connects via B2B devices that sit under your PRODA organisation. That’s where having a clear, deliberate access design becomes non‑negotiable. You can’t just keep handing out logins and hoping for the best.

Will, EnableUs Community

Yeah, you wanna be able to say, “For this role, we use RAM and myID in this way, and PRODA in that way,” instead of reinventing it every time you hire someone. If you get the foundations sorted – PRODA for Commission stuff, RAM plus myID for myplace operations – everything else becomes much easier to scale and much easier to secure.

Winter, EnableUs Community

So in the rest of the episode we’re gonna unpack exactly how to set staff up properly in RAM, how PRODA attributes map to job roles, and how to keep your software connections and offboarding tight so you don’t end up with mystery access hanging around.

Chapter 2

Setting Up Staff Access the Smart Way

Will, EnableUs Community

Alright, let’s walk through what smart onboarding actually looks like now. Say you’ve just hired a new admin officer who’s going to process payment claims in myplace.

Winter, EnableUs Community

Step one is not PRODA. It’s their personal myID. They go and create that themselves using their own personal email. And this is really important: don’t shortcut it with a work email. The myID belongs to the person, not the organisation.

Will, EnableUs Community

Yeah, because that digital identity follows them when they leave. Once they’ve set up myID, the principal authority – or whoever handles RAM for your business – logs into RAM at authorisationmanager.gov.au using their own myID and creates a new authorisation for that staff member.

Winter, EnableUs Community

They pick the business, start a new authorisation, and enter the staff member’s personal email – exactly the one that’s on their myID. Then they choose which agencies and services apply. For myplace, you’d select the NDIS‑related options from the list so this person can act on behalf of your organisation.

Will, EnableUs Community

RAM then emails that staff member an authorisation request with an acceptance code. And here’s the gotcha: until they log into RAM with their myID and accept that request using the code, they cannot actually access myplace on your behalf. Creating the authorisation alone isn’t enough.

Winter, EnableUs Community

Once they’ve accepted, they just log into myplace using myID, and RAM tells myplace, “Yep, this person is authorised for this organisation.” No extra linking steps needed. That’s operational access done.

Will, EnableUs Community

Now, on the PRODA side, we’ve got this whole concept of attributes, which is where role design really kicks in. Attributes are like permission bundles you can delegate to members of your PRODA organisation.

Winter, EnableUs Community

So, quick rundown of the key ones. Service‑user attributes give access to particular government services – things like NDIS myplace, the NDIS Commission Portal, Medicare Online, the Australian Immunisation Register. If someone has that attribute, they can log into that service with their personal PRODA under your organisation.

Will, EnableUs Community

Then you’ve got Member‑Management attributes. That’s your “mini‑admin” power. It lets someone add members to the organisation and delegate attributes. You only want trusted senior staff with that, because they’re effectively controlling who gets in.

Winter, EnableUs Community

Device‑Management attributes control B2B devices – registering them, activating, extending, removing. So that’s your IT manager, practice manager, or whoever is responsible for your software connections, not random support workers.

Will, EnableUs Community

And finally, Service‑Link Management attributes. That’s higher‑level again – linking your organisation to new government services. Usually that stays with the principal authority or directors, because you’re effectively deciding which systems the business can interact with.

Winter, EnableUs Community

So how do you turn that into something usable? Design “access levels by role.” For example, support workers and support coordinators: give them only the service‑user attribute for myplace so they can see participant details with consent, manage bookings, maybe lodge claims if that’s your process – and that’s it.

Will, EnableUs Community

Admin and finance staff: still service‑user for myplace, maybe also service‑user for the Commission Portal if they handle incident reports or help with registration, but usually no member‑management, no device‑management.

Winter, EnableUs Community

Compliance or quality managers: they almost always need Commission Portal access and often myplace too, and they might also get member‑management if they’re the ones onboarding staff. IT or practice managers: device‑management, maybe no portal access at all if they’re purely technical.

Will, EnableUs Community

And your owners or directors? Usually broad service‑user access, plus member‑management, and maybe device‑management depending on how hands‑on they are.

Winter, EnableUs Community

The last piece is documenting it. Even a simple one‑page chart – role down the left, attributes across the top, ticks in the boxes – makes onboarding consistent and makes audits so much easier, because you can show you’ve thought about who needs what and why.

Chapter 3

B2B Devices, Security Reviews and Offboarding Without Gaps

Will, EnableUs Community

Let’s talk about the invisible worker in your business: your software. That’s where B2B devices come in.

Winter, EnableUs Community

Yeah, B2B – business‑to‑business – devices are essentially the secure keys your software uses to talk to government services. So your NDIS client management system might use a B2B device to send payment claims to myplace without you logging in manually every time.

Will, EnableUs Community

Only people with Device‑Management attributes in PRODA can manage these. If you’re the principal authority, you already have it. Otherwise you delegate Device‑Management to the right technical person – often IT or a practice manager – before they touch any devices.

Winter, EnableUs Community

The workflow is pretty straightforward. You log into PRODA, go to Organisations, pick your organisation, and open B2B Devices. Hit “Register New B2B Device.” Then give it a clear name that tells you what it’s for – like “NDIS Client Management Software – Main Office” or “Medicare Online – Clinic A.”

Will, EnableUs Community

You can add a description too, which is handy six months later when you’re wondering, “What on earth was this for?” Then you click register, and PRODA gives you a Device Activation Code that’s valid for seven days. You see it once, and that’s it, so you copy it and store it securely straight away.

Winter, EnableUs Community

You pass that activation code to your software admin or vendor, they plug it into the software settings, and that activates the connection. Once it’s active, the device will stay live for six months, and then it expires automatically unless someone with Device‑Management extends it. If you forget, your integration just stops working.

Will, EnableUs Community

Which is why security reviews matter. Let’s sketch a basic checklist you can run regularly. First, RAM: review all current authorisations. Is everyone still employed? Are they still in the same role? Revoke any RAM authorisations that are no longer needed.

Winter, EnableUs Community

Then PRODA: check your organisation’s member list. Does it match your current team? Remove anyone who’s left and tighten attributes for people whose role has changed. Ask yourself, “Does this person still need Commission Portal access? Do they really need member‑management?”

Will, EnableUs Community

And third, B2B devices: go through the device list in PRODA. You should be able to recognise every device and explain what system it links and why it exists. If something looks like a test device you’re not using anymore, remove it. Unknown devices are a red flag.

Winter, EnableUs Community

Now, offboarding. This is where gaps creep in if you’re not systematic. When someone leaves, you need both systems covered. In RAM, you revoke their authorisations straight away so they can’t get into myplace or other operational portals for your organisation.

Will, EnableUs Community

Then in PRODA, you remove them from your organisation’s membership. That instantly cuts their access to the Commission Portal and anything else they did through your PRODA organisation. Their personal PRODA account still exists – it’s just no longer linked to your business.

Winter, EnableUs Community

If they’re staying with you but changing roles, you don’t have to remove them completely. You can just strip back specific attributes in PRODA – like taking away member‑management or Commission Portal access – and adjust their RAM authorisations so their myplace access matches the new job.

Will, EnableUs Community

And always, always document it. Note who removed which member or attribute, when it happened, and what access they used to have. If an auditor ever asks, you can show that access isn’t just accumulating forever – you’re actively managing and reviewing it.

Winter, EnableUs Community

So to wrap up, if you get three things right – clear split between PRODA and RAM, role‑based access with documented attributes, and disciplined reviews and offboarding – you set yourself up to grow without your access systems turning into spaghetti.

Will, EnableUs Community

We’ll keep unpacking the practical side of NDIS systems in future episodes, so if there’s a specific PRODA or myplace headache you want us to cover, let us know.

Winter, EnableUs Community

Thanks for hanging out with us today. Will, always good to nerd out over access control with you.

Will, EnableUs Community

Likewise, Winter. Alright everyone, look after yourselves and your logins, and we’ll catch you next time.