IT & operations
Security, single sign-on and API answers for university IT teams
Before a college or university signs, IT and data protection reviewers ask the same things: how staff sign in, who can see and export what, what gets logged and how data moves in and out. This page answers each, with the limits stated plainly.
Covers IT, security, data protection and operations reviewers.
The questions IT asks before saying yes
An admissions CRM holds contact details for every applicant. Reviewers want the controls before the features.
Another set of passwords
Separate logins mean more resets, weaker passwords and accounts that linger after people leave.
Everyone can export everything
Without permissions per action, any user can download the full contact list.
No trail when something changes
When a stage, a role or a phone number changes, you need to know who did it, from where and when.
Integration requests pile up
Websites, landing pages and other systems all need an approved, secured way to send data in.
How control works
Permissions set per page and per action
Each custom role is a checklist of pages grouped by area, with the actions allowed on each. Staff sign in through your OpenID Connect identity provider, with MFA optional or mandatory.
One drawer per role
Name the role and give it a color, starting from a template, a duplicate of another role or an import.
Pages grouped by area
Sales, communication and marketing pages sit in groups, and every role change is written to the audit log.
Actions per page
View, create, edit, delete and export are separate checkboxes, so export can stay off for most roles.
Masking enforced on the server
Masked contact details apply everywhere, including exports and conversations, while staff can still call and write.
Is it a fit for your security and integration requirements?
The controls in place today, and the gaps to record in your review.
A good fit when you need
- Sign-in through an OpenID Connect identity provider, with MFA optional or mandatory
- Audit logs with old and new values, IP, device and session, plus each lead's own history
- A REST API to create and read leads, with scoped keys, quotas and IP allow-lists
Check these before you shortlist us
SAML isn't supported, and we hold no third-party security certifications.
We answer your security questionnaire in full, and the trust center lists each control.
There are no outbound webhooks and no packaged SIS connector.
Your systems read leads through the API, and inbound webhooks, verified by a secret header or signature, start workflows.
IP allow-lists apply to API keys, not to staff sign-in.
Protect sign-in with single sign-on and MFA; deactivating a user signs them out everywhere.
FAQ
Questions from IT and security reviewers
What is encrypted?
Stored provider and integration credentials, and custom fields marked "Encrypt data at rest", use AES-256-GCM; marked fields show masked in the app. Hosting and wider encryption details are confirmed in writing during your review.
What does the REST API cover?
Creating and reading leads. Keys are scoped and carry quotas, can be revoked, rotated and reactivated, and each one can be limited to an IP allow-list.
How does higheredcrm.ai help with GDPR and FERPA?
Do-not-contact and per-channel opt-outs checked before every send, contact masking by role, page-level permissions, audit logs and field encryption help you meet obligations under GDPR, FERPA and similar laws. Compliance depends on how you use the system.
Can an administrator end another user's sessions?
Each user sees their own active sessions and can end any of them or log out of every device. Administrators can't end someone else's session directly, but deactivating a user signs them out everywhere.
Where should our review start?
With the trust center's security and procurement pack, the scorecard and RFP kit's security checklist and the developer docs. We can also run a separate technical session and answer your questionnaire in writing.
Bring your security questions to the walkthrough.
Bring your IT and data protection reviewers and your questionnaire. We'll cover sign-in, roles, logging and the API in the product, then answer the rest in writing.