Aula Education Ltd

Digital Communication Platform for Higher Education

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.

Features

  • 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

Benefits

  • 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.

Pricing

£24 per user per year

  • Education pricing available

Service documents

G-Cloud 11

961975434203090

Aula Education Ltd

Anders Krohn

07512240611

anders@aula.education

Service scope

Service scope
Software add-on or extension No
Cloud deployment model Public cloud
Service constraints None
System requirements Internet connection

User support

User support
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 Yes
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
Support levels 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

Onboarding and offboarding
Getting started 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.
Service documentation Yes
Documentation formats PDF
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

Using the service
Web browser interface Yes
Supported browsers
  • Microsoft Edge
  • Firefox
  • Chrome
  • Safari 9+
  • Opera
Application to install Yes
Compatible operating systems
  • Android
  • IOS
  • Linux or Unix
  • MacOS
  • Windows
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
Accessibility testing None
API Yes
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 Yes
API documentation formats Open API (also known as Swagger)
API sandbox or test environment Yes
Customisation available No

Scaling

Scaling
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.

Analytics

Analytics
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.
Reporting types
  • API access
  • Real-time dashboards
  • Regular reports
  • Reports on request

Resellers

Resellers
Supplier type Not a reseller

Staff security

Staff security
Staff security clearance Conforms to BS7858:2012
Government security clearance Up to Baseline Personnel Security Standard (BPSS)

Asset protection

Asset protection
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 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-in-transit protection

Data-in-transit protection
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

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

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

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

Standards and certifications
ISO/IEC 27001 certification No
ISO 28000:2007 certification No
CSA STAR certification No
PCI certification No
Other security certifications Yes
Any other security certifications CyberEssentials Plus

Security governance

Security governance
Named board-level person responsible for service security Yes
Security governance certified Yes
Security governance standards
  • ISO/IEC 27001
  • Other
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.

Operational security

Operational security
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.

Secure development

Secure development
Approach to secure software development best practice Conforms to a recognised standard, but self-assessed

Public sector networks

Public sector networks
Connection to public sector networks No

Pricing

Pricing
Price £24 per user per year
Discount for educational organisations Yes
Free trial available No

Service documents

pdf document: Pricing document pdf document: Terms and conditions pdf document: Modern Slavery statement
Service documents
Return to top ↑