Aula is a communication platform which brings engagement to the core of the digital student experience, replacing the virtual learning environment. We partner with universities to transform course content and harness behaviour data to drive engagement, enabling incredible teaching and learning to happen in every class, every time.
- Enable intuitive communication through course-wide posts and instant messaging.
- Organise course material and assignments.
- Automatically populate students, educators and spaces through an SRS integration.
- Interact through posts, comments, messages and reactions (emojis).
- Integrate content, file-storage (e.g OneDrive) & assessment (e.g. Turnitin).
- Communicate using, images, video, voice-recording, code, LaTeX, and embedded integrations.
- Make announcements and send reminders.
- Native iOS and Android mobile apps.
- Ongoing change-management support from our Learning Intelligence team
- Saves academics’ time by streamlining communication and reducing task duplication.
- Substantially increases student engagement compared to traditional VLE/LMS alternatives.
- Results in positive student feedback around learning experience and community.
- Makes collaboration and cross-departmental work easier by connecting all students.
- Addresses key causes for non-continuation through building communities.
- Supports widening participation through spaces that are accessible from anywhere.
- Gives competitive advantage in recruitment by using consumer standard technology.
- Supports employability by mirroring modern workplace software.
£24 per user per year
- Education pricing available
Aula Education Ltd
|Software add-on or extension||No|
|Cloud deployment model||Public cloud|
|System requirements||Internet connection|
|Email or online ticketing support||Email or online ticketing|
|Support response times||Under 30 minutes for first response. No difference on weekends.|
|User can manage status and priority of support tickets||No|
|Phone support availability||9 to 5 (UK time), Monday to Friday|
|Web chat support||Web chat|
|Web chat support availability||24 hours, 7 days a week|
|Web chat support accessibility standard||WCAG 2.1 AA or EN 301 549|
|Web chat accessibility testing||None.|
|Onsite support||Onsite support|
We provide two different types of support for our customers, at no extra cost.
Technical Support: We provide reactive user support, as well as bespoke technical account manager support for administrators.
Pedagogical Support - We supply bespoke support for all educators on the use of platform to support student outcomes.
|Support available to third parties||Yes|
Onboarding and offboarding
To implement the product, we have our highly specialised implementation/learning intelligence team. They add all capacity necessary for the implementation to be a success. This includes full onboarding, workshops with all educators, inductions for students, and continuous, proactive feedback and support, through in person meetings or calls and user documentation as required.
The platform itself has some online training within the platform.
|End-of-contract data extraction||Through EBV volume snapshot and transfert or through mongodump in an S3 bucket.|
|End-of-contract process||In the price of the contract includes full use of the platform, including updates (at the scope agreed in the Statement of Work) and full Learning Intelligence support. This ends at the end of the contract. There are no additional costs.|
Using the service
|Web browser interface||Yes|
|Application to install||Yes|
|Compatible operating systems||
|Designed for use on mobile devices||Yes|
|Differences between the mobile and desktop service||
Aula has been designed as a web platform (browser and desktop app) and a mobile iOS and Android app. The majority of the functionalities that exist on the web version are also available on the mobile applications. In most cases, the usage from a student perspective is higher on mobile.
There are slight differences between web and mobile for example through edit functionalities, but fundamentally Aula has been designed for mobile first use cases.
|Accessibility standards||WCAG 2.1 AA or EN 301 549|
|What users can and can't do using the API||
Aula provides a standard REST API for its users, spaces, roles and services.
They can make changes by doing a post request, and there are no limitations to how users can set up or make changes.
|API documentation formats||Open API (also known as Swagger)|
|API sandbox or test environment||Yes|
|Independence of resources||Aula uses Terraform ('Infrastructure as Code') to provide each institution with a dedicated environment, that has its own separate networks, servers and database.|
|Service usage metrics||Yes|
|Metrics types||Regular reporting direct to customer and real-time dashboard serviced through an API which we use to create the reporting.|
|Supplier type||Not a reseller|
|Staff security clearance||Conforms to BS7858:2012|
|Government security clearance||Up to Baseline Personnel Security Standard (BPSS)|
|Knowledge of data storage and processing locations||Yes|
|Data storage and processing locations||Other locations|
|User control over data storage and processing locations||Yes|
|Datacentre security standards||Complies with a recognised standard (for example CSA CCM version 3.0)|
|Penetration testing frequency||At least every 6 months|
|Penetration testing approach||In-house|
|Protecting data at rest||Encryption of all physical media|
|Data sanitisation process||Yes|
|Data sanitisation type||Deleted data can’t be directly accessed|
|Equipment disposal approach||In-house destruction process|
Data importing and exporting
|Data export approach||The data is owned by the university and we use data that they can already access.|
|Data export formats||Other|
|Other data export formats||JSON|
|Data import formats||Other|
|Other data import formats||JSON|
|Data protection between buyer and supplier networks||TLS (version 1.2 or above)|
|Data protection within supplier network||TLS (version 1.2 or above)|
Availability and resilience
|Guaranteed availability||To achieve high availability, our server deployment span across two AWS availability zones.|
|Approach to resilience||
Aula routinely carries out tests of its Business Continuity Arrangements on a monthly basis by refreshing pre-production environments (e.g. Beta and Test environments) with data from archives located in a geographically discrete location. If three or more Test Implementation failures occur in a 12-month period, we will inform the institutions of the failure and any planned responses.
Aula uses a microservice architecture with multiple levels of failure handling:
Process level: if a process dies inside of a container it is instantly restarted
Container level: if a container dies or becomes unresponsive it is restarted automatically by our orchestrator
Machine level: if a machine dies (disk, network…) it is automatically replaced by another instance in our clusters.
Every service is redundant (at least 2 copies), machines are distributed across AZs (availability zones) and are being monitored for failure.
Failure is a process that we embrace and recover transparently from.
Users are mostly never affected by failures in the system.
|Outage reporting||Email alerts shared directly with project board, service desk and relevant senior academic stakeholders, followed by comms to wider academic community once approved by relevant stakeholders.|
Identity and authentication
|User authentication needed||Yes|
|User authentication||Identity federation with existing provider (for example Google Apps)|
|Access restrictions in management interfaces and support channels||
We have 3 roles: educator, student and admin.
Students have read access for space data and write access for their own (e.g. they can't delete or edit other people's content, or edit class material).
Educators have read and write access for a given space (can edit class material, can delete any post or comment).
Admin can manage users and spaces.
|Access restriction testing frequency||At least every 6 months|
|Management access authentication||Public key authentication (including by TLS client certificate)|
Audit information for users
|Access to user activity audit information||Users contact the support team to get audit information|
|How long user audit data is stored for||Between 1 month and 6 months|
|Access to supplier activity audit information||Users contact the support team to get audit information|
|How long supplier audit data is stored for||Between 1 month and 6 months|
|How long system logs are stored for||Between 1 month and 6 months|
Standards and certifications
|ISO/IEC 27001 certification||No|
|ISO 28000:2007 certification||No|
|CSA STAR certification||No|
|Other security certifications||Yes|
|Any other security certifications||CyberEssentials Plus|
|Named board-level person responsible for service security||Yes|
|Security governance certified||Yes|
|Security governance standards||
|Other security governance standards||AWS is ISO/IEC 27001 compliant.|
|Information security policies and processes||Our CTO Oliver is responsible for maintaining Aula's security policies. He is also responsible for training staff on our security practices. Every line of code is secure using up-to-date industry standard techniques, including static code analysis for every line in production.|
|Configuration and change management standard||Supplier-defined controls|
|Configuration and change management approach||Every major changes in the environment (infrastructure and code) that could affect the institution's security posture are communicated immediately to the institution. In order to enable the best user experience and to make sure that the latest security fixes are applied, every institution is running the latest version of the Aula platform. Emergency changes are always documented in a github issue, then reviewed and approved before deployment as any other production code.|
|Vulnerability management type||Supplier-defined controls|
|Vulnerability management approach||
We use ESLint and Snyk to scan for vulnerabilities in our applications and systems, as well as using strict data validation on the server side.
Every line of code is secure using up-to-date industry standard techniques, including static code analysis for every line in production.
Critical patches on Aula's code are deployed as soon as it is discovered and fixed. Critical patches on our host machines are applied every 36h at most.
|Protective monitoring type||Supplier-defined controls|
|Protective monitoring approach||
We use DDos detection and mitigation. We also use a monitoring service based on the tick stack and alerting on suspicious activities.
We use the AWS services 'X-Ray' and 'Inspector' to detect intrusion.
We respond to incidents instantaneously by taking the affected service offline immediately and working on it straight away.
|Incident management type||Supplier-defined controls|
|Incident management approach||All errors are flagged to the end-user directly and all errors are logged. Errors are available to every admin directly through Kibana. All major incidents reported are responded to immediately.|
|Approach to secure software development best practice||Conforms to a recognised standard, but self-assessed|
Public sector networks
|Connection to public sector networks||No|
|Price||£24 per user per year|
|Discount for educational organisations||Yes|
|Free trial available||No|