Security and audit
Use security settings, session policy, API access, and audit logs to protect an Edmissa workspace.
Security and audit settings help admins protect access to the workspace and understand important activity after it happens.
Use this hub when you are setting up account protection, reviewing session behavior, creating API tokens, or checking audit history. These settings protect student profiles, Leads, applications, documents, user access, and workspace configuration.
What this guide helps configure
| Area | Open this page | Use it for |
|---|---|---|
| Security settings | /t/settings/security | Review the security controls available for your workspace and save planned changes. |
| Session policy | /t/settings/security/sessions | Review how user sessions should behave for your team. |
| API access | /t/settings/api-access | Generate and manage tokens for approved system connections. |
| Audit logs | /t/settings/audit-logs | Filter, review, and export workspace activity history. |
Before you start
Prepare these items before changing security or audit settings:
| Item | Why it matters |
|---|---|
| Admin access | You need permission to open the related settings pages. |
| User and role plan | Security settings work best when users, roles, permissions, and locations are already organized. |
| Change owner | Decide who approves changes that affect sign-in, sessions, or API tokens. |
| Test user | Use a safe test user to confirm that the change works before relying on it for the full team. |
| Review reason | Write down why you are making the change so future admins understand the decision. |
If you are still setting up access, start with users, roles, and permissions and scope.
Security Settings
Open /t/settings/security.
The page title is Security Settings. Use this page to review the security settings available in your workspace. When the changes are ready, select Save Security Settings.
Use a careful rhythm for this page:
- Review the current settings before changing anything.
- Change only the settings you meant to change.
- Save the settings.
- Test sign-in and access with a safe user account.
- Record what changed and why.
Avoid making several access-related changes at the same time. If users have trouble signing in later, smaller changes are easier to review and correct.
Session Policy
Open /t/settings/security/sessions.
The page title is Session Policy. Use this page to review how signed-in sessions should work for users in the workspace.
Session policy matters because many study abroad teams use shared office computers, remote work, and multiple branch locations. A practical policy should balance convenience with protection for student profiles, applications, and documents.
After updating session policy, test with at least one admin user and one normal team user. Confirm that users can continue daily work and that the policy feels appropriate for your agency's operating style.
API Access
Open /t/settings/api-access.
The page title is API Access. Use this page when an approved system needs a token to connect with the workspace. Select Generate Token when you need to create a new token.
Treat tokens like passwords:
- Generate tokens only for approved systems or trusted internal work.
- Give each token a clear business purpose.
- Share tokens only through a secure channel.
- Remove or replace tokens that are no longer needed.
- Review token access when a team member or vendor relationship changes.
Do not create a token just to avoid giving a person the correct user account or role. People should normally use their own Edmissa user account so access and activity stay clear.
Audit Logs
Open /t/settings/audit-logs.
The page title is Audit Logs. Use this page to review workspace activity. The page includes filters by date, user, action, and type. Select Export when you need a copy of the filtered results.
Audit logs help answer questions such as these examples:
| Question | Useful filter |
|---|---|
| Who changed a setting during a certain week? | Date and action |
| What activity is tied to one user? | User |
| Which actions happened before an access issue was reported? | Date and action |
| What type of activity should be reviewed for a handover? | Type |
Use exports for formal reviews, handovers, and issue investigations. Keep exports in a secure place because they may include sensitive workspace activity details.
Recommended first version for study abroad agencies
For a first setup, keep the model simple and easy to review:
- Give each team member their own user account.
- Keep admin access limited to trusted staff who manage configuration.
- Use roles that match real jobs, such as counselor, manager, coordinator, reviewer, and admin.
- Review security settings before inviting the full team.
- Use a session policy that fits your office and remote-work habits.
- Generate API tokens only for approved systems with a clear purpose.
- Review audit logs after major access changes.
- Export audit logs when you need a shared review file.
Start with a stricter setup, then expand access when the work clearly needs it. It is easier to grant more access later than to clean up broad access after people have started using it.
Safe change guidance
Use this checklist before saving a security, session, or API access change:
| Step | What to do |
|---|---|
| Plan | Write down what is changing, who asked for it, and who it affects. |
| Notify | Tell affected users before a change that may affect sign-in or active work. |
| Change | Make the smallest useful change. |
| Test | Confirm daily work still opens for the right users. |
| Review | Check audit logs after sensitive access changes. |
| Document | Keep a short note for the next admin who reviews the setup. |
If a change causes an access problem, use Access and permissions troubleshooting to check account status, role assignment, permissions, scope, and location access.
Test after setup
After the first setup or any important change:
- Sign in as an admin and confirm the settings pages open as expected.
- Sign in as a normal team user and confirm restricted settings are hidden.
- Open sample student profiles, Leads, applications, and documents that the user should be able to work with.
- Confirm the same user cannot open work or settings outside their role.
- Create or review one harmless activity, then confirm it appears in audit history.
- Use the audit log filters by date, user, action, and type.
- Export a filtered audit log if your agency needs a review file.
Test in more than one location if your agency works across multiple branches.
Related guides
| Guide | Use it for |
|---|---|
| Users | Add users, review account status, reset passwords, and manage sessions from user management. |
| Roles | Create reusable access profiles for job responsibilities. |
| Permissions and scope | Understand what users can see and do. |
| Session Policy | Configure timeout warnings, session limits, and extra checks for sensitive actions. |
| API Access | Manage tokens for approved external tools and integrations. |
| Audit Logs | Review activity history, investigate changes, and export filtered audit results. |
| Access and permissions troubleshooting | Diagnose missing pages, disabled actions, and access problems. |