Domain suffix restrictions for private portals

It would be useful to extend Domain Restricted portal privacy so that access can be granted based on an email domain suffix, rather than requiring every individual domain to be added. Our use case We work exclusively with organisations in the education sector and have around 60 client institutions. We want our Sleekplan portal to be private and accessible to our clients, but the existing privacy options don’t quite fit: Public isn’t appropriate because we don’t want the roadmap visible to everyone. Password protected creates a shared credential that needs to be distributed and can easily be passed on. SSO/SAML isn’t practical because our users belong to many separate client organisations. Domain restricted is very close to what we need, but maintaining a list of 60+ individual client domains creates unnecessary administration. It also means remembering to update Sleekplan every time we onboard a new client. Suggested improvement Allow domain restrictions to support suffix or wildcard matching. For example, instead of entering individual domains: university-a.edu university-b.edu college-c.edu an administrator could allow: *.edu Any user whose verified email address ends with .edu would then be permitted access. Ideally, this could support multiple suffixes or wildcard rules where required. Why this would be useful This would create a useful middle ground between a public portal and managing individual organisations. For sectors where organisations use recognisable domain namespaces, an administrator could configure the access rule once and new organisations would automatically qualify without needing to be manually added. It would make Domain Restricted portals considerably more scalable for organisations serving a large number of clients within the same sector.