We just started granting Domains accounts to students as part of two different courses (~30 students so far). Is there a way I can tag user accounts as student vs. faculty vs. staff? I’m not sure where I’d go to create such a list or view of users (WHM, WHMCS?) Does this already exist somewhere? I’m thinking this will help me keep track of when the students are nearing graduation, for example. But I’d be happy to hear from other DoOO admins about how they keep track of who gets Domains accounts.
Hi Christine! One way you could organize users within WHMCS would be using Client Groups. Under the menu item Setup you will find Client Groups where you can create the groups. I would only set the Group Name and Color, as the other settings aren’t helpful from a DoOO standpoint.
Then you can add users to the group by going to their WHMCS profile and under the Profile tab changing the Client Group from the drop-down:
Once that’s done, you can sort by Client Group within View/Search Clients.
I’d love to see how other schools might be organizing things on their end as well!
I keep a separate spreadsheet of all applications on our instance of Domains at Grinnell, with columns for site title, URL, account owner, principle use, and other notes. I have separate sections of the spreadsheet for faculty/staff and students. It is a bit of extra work to keep the spreadsheet up to date, but it gives me a document that I can easily share with others (especially administrators at the college) to demonstrate the extent of how Domains is being used on campus and to bolster the case for further growth of our platform at the college.
Hi! I’m just reading this and I love it. Where do you pull the data from overall? I should start doing this at our institution.
We have a different convention for student email addresses versus faculty/staff email addresses, so that is how I know the difference between our accounts. I also get a lot of use out of the signup date field in WHMCS. This summer I plan to apply a lot more use of WHMCS to hold, as you suggest, class year and perhaps affiliation (student, student+1, staff, faculty).
Right now, all our accounts are auto-provisioned after I add access in our SSO. When I remove accounts, I have to do it in two places and it’s a lot of dull work. I’d really like to take full advantage of APIs, our Student Information System, and our SSO so that, upon account creation/removal, WHMCS already has useful (but only the most necessary) information.
And a dream would be to use the automatic email capability of WHMCS to notify client groups (like seniors) about how to access their domains after graduation, and how to migrate them after that.
What questions should I prepare for my OIT folks, and what should I study in the WHM/WHMCS docs to feel informed and have productive meetings?
I’m not really pulling the data from anywhere specifically … we’re still at a small enough scale (~ 150 accounts) such that, every time I create a new cpanel or add a new application to an existing account, I manually update the speadsheet.
We are in the process of transitioning from managed hosting to a full-on Domain of One’s Own instance, so will just be beginning to use WHMCS for client management (currently I do everything in WHM). So perhaps I will begin to utilize WHMCS to track and tag user data, as others are pointing out in this thread.
Thanks for responding. We have over 1,000 accounts, so I’m still trying to wrap my head around the best way to manage say account users - I do a manual deletion process ever year I’ve got that process well figured out at this point, but for tracking active users I would love some better ideas around that!
I wish there was a way to use WHMCS more and better to manage users. I mean it’s literally a system used to manage payments and on boarding, so shouldn’t there be a way to better use this system.
The DoOO guides try to encourage us to pull data from 3 different areas.
- On my portal, we use the Wordpress “last logged in” plugin to try to understand who is an active user of the platform. Of course this doesn’t work at all if they use the application login instead of the DoOO integrated login.
- We look at WHM bandwidth to try to know who has most visited sites.
- We use the first sign in dates in WHMCS.
I was wondering, instead of making our service free, could we assign a $$ amount to hosting, and create a “1 year free trial” code that students put in? And then next year they got a new 1 year free coupon until it’s time to graduate.
That way, every year they just need to renew their website and say, yes I’m still using this, or get deactivated. We could also build into the automated emails the stock information about migrating to a new server.
Just my imagination I’m afraid. It’s what I wish we had.
WHMCS unfortunately has no way of processing a coupon code for a renewal, it only generates an invoice at which point the user gets stuck. It’s something we’ve longed for even on our public hosting side.
Just a dream!
I’m just now getting around to reading through all of the suggestions here and preparing to dive in to actually start managing users this semester. Thanks @katiehartraft for pointing out Client Groups in WHMCS. It’ll be helpful to be able to send a mass email to these client groups.
I do spend time in WHM with the “list accounts” feature. Is there any way to add another field there to see whether users are faculty/students/staff? (similar to “client groups” in WHMCS)
@Erika_Rydberg what is your process for manually deleting users every year?
Has anyone else discovered any new tips or tricks for managing users?
I think one thing that would be necessary to distinguish student from faculty from staff is an integration at the single sign-on level with you information systems to make that distinction and push them into different packages through WHMCS that would register in WHM. The issue there is providing any vendor more access to information about your students/faculty/staff, so while it may be possible it is often a concern for the institution. What’s more, getting that kind of data from your campus system might require some development depending on the system you are using.
So while it is possible, the bigger question is whether your school IT department would provide their blessing, and then how simple or difficult the integration may be. So, in short, it may not be possible seamlessly via SSO.
That said, if you have folks identify themselves use a radio button at the point of sign-up, it might be possible but not necessarily automatic or fully reliable.
This topic was automatically closed after 365 days. New replies are no longer allowed.