How OWL Services Work in Odoo Frontend Architecture

4.1 Service Registration

Services are registered in the global OWL registry at module load time — before the application even starts. The registry is a simple key-value store maintained under the 'services' category. When your JavaScript module is executed, it calls:

registry.category('services').add('myService', myServiceDefinition);

This just adds a definition to the registry. Nothing executes yet. The service definition is a plain JavaScript object with at minimum a start() method, and optionally a dependencies array.

4.2 Dependency Resolution and Startup

When the Odoo web client boots, OWL iterates the services registry. For each service, it looks at the dependencies array and resolves those services first. This is a topological sort — services with no dependencies start first, and services that depend on others wait until their dependencies are ready.

Once dependencies are resolved, OWL calls start(env, deps) where:

• env is the OWL application environment — a shared object containing utilities like translations, the event bus, and service references.
• deps is an object containing the already-initialized service instances for each declared dependency.

If start() returns a Promise, OWL awaits it before marking the service as ready. The resolved value (or the synchronous return value) becomes the service instance stored in env.services.

4.3 Environment Injection

Once all services are started, they live in env.services. Components access them through the useService() hook in their setup() function. The hook retrieves the live service instance from env.services and returns it to the component.

4.4 Component–Service–Backend Communication Flow

Here's the typical data flow in an OWL application:

Notice how the component never talks to the backend directly. It talks to a service, and the service handles backend communication. This clean separation makes the flow predictable and testable at every layer.

4.5 Async Handling

Most service operations are asynchronous. OWL marks services with an async flag when their API is async-heavy. When a component gets destroyed before a pending Promise resolves, OWL safely drops the result — preventing updates to unmounted components and avoiding dangerous side effects. This is handled transparently; you don't need to manage it manually.

6.1 orm

The ORM service is your primary interface for interacting with Odoo's database through the frontend. It wraps common record operations — search, read, create, write, unlink — behind a clean async API.

import { useService } from '@web/core/utils/hooks';
 
setup() {
  this.orm = useService('orm');
  onWillStart(async () => {
    this.partners = await this.orm.searchRead(
      'res.partner',
      [['is_company', '=', true]],
      ['name', 'email', 'phone'],
      { limit: 20 }
    );
  });
}

Use case: Loading data in dashboards, filtering records for dropdowns, saving form fields without a full form view.

6.2 rpc

The rpc service handles direct RPC calls to custom Odoo controllers or Python routes. In OWL 1, you used useService('rpc'). In OWL 2 (Odoo 18+), this became a direct import:

// OWL 1 pattern
this.rpc = useService('rpc');
const result = await this.rpc('/my/custom/route', { key: value });
 
// OWL 2 pattern (Odoo 18+)
import { rpc } from '@web/core/network/rpc';
const result = await rpc('/my/custom/route', { key: value });

6.3 notification

Display toast messages to the user — success, warning, danger, or info. This is one of the most commonly used services in day-to-day Odoo development.

this.notification = useService('notification');
 
// Simple success toast
this.notification.add('Record saved successfully!', { type: 'success' });
 
// Sticky warning notification
this.notification.add('Connection lost', {
  type: 'warning',
  sticky: true,
});

Use case: Post-save confirmations in sales orders, error feedback after failed API calls, status updates in POS workflows.

6.4 dialog

The dialog service lets you open modal dialogs programmatically — confirmation dialogs, form dialogs, custom OWL components as modals.

this.dialog = useService('dialog');
 
this.dialog.add(ConfirmationDialog, {
  title: 'Delete Record',
  body: 'Are you sure you want to delete this record?',
  confirm: async () => {
    await this.orm.unlink('sale.order', [this.orderId]);
    this.notification.add('Order deleted', { type: 'info' });
  },
  cancel: () => {},
});

6.5 action

The action service is how you programmatically trigger Odoo actions — opening views, running server actions, navigating to forms.

this.action = useService('action');
 
// Open a form view for a specific record
await this.action.doAction({
  type: 'ir.actions.act_window',
  res_model: 'sale.order',
  views: [[false, 'form']],
  res_id: orderId,
});

6.6 user

The user service provides access to the current user's session data — ID, name, groups, language, timezone, and the user context used in ORM calls.

this.user = useService('user');
console.log(this.user.name);       // 'Administrator'
console.log(this.user.lang);       // 'en_US'
console.log(this.user.context);    // { lang, tz, uid }
const isSalesManager = await this.user.hasGroup('sales_team.group_sale_manager');

6.7 router

The router service manages the browser URL and navigation — reading URL parameters, pushing state changes, handling back/forward navigation.

6.8 effect

The effect service triggers UI effects like the Rainbow Man animation on successful actions.

this.effect = useService('effect');
this.effect.add({ type: 'rainbow_man', message: 'Quotation confirmed!' });

6.9 ui

The ui service handles application-level UI state — blocking the interface during loading, managing active element tracking, and blocking/unblocking user interactions.

6.10 bus

The bus service provides Odoo's global event bus for cross-component and cross-service communication. Components and services can publish and subscribe to named events without direct references to each other.

this.busService = useService('bus_service');
this.busService.subscribe('MAIL_NOTIFICATION', (message) => {
  this.handleIncomingMessage(message);
});

7.1 Service Definition

A service definition is a plain JavaScript object with an optional dependencies array and a required start() method. The start() function receives the env and resolved dependencies, then returns the service's public API.

// services/customer_service.js
import { registry } from '@web/core/registry';
 
const customerService = {
  dependencies: ['orm', 'notification'],
 
  async start(env, { orm, notification }) {
    // Internal state
    const cache = new Map();
 
    // Service methods
    async function getCustomer(partnerId) {
      if (cache.has(partnerId)) {
        return cache.get(partnerId);
      }
      try {
        const [partner] = await orm.read(
          'res.partner',
          [partnerId],
          ['name', 'email', 'phone', 'city']
        );
        cache.set(partnerId, partner);
        return partner;
      } catch (err) {
        notification.add('Failed to load customer', { type: 'danger' });
        throw err;
      }
    }
 
    async function searchCustomers(domain, limit = 10) {
      return orm.searchRead('res.partner', domain,
        ['name', 'email'], { limit });
    }
 
    function clearCache() {
      cache.clear();
    }
 
    // Return the public API
    return { getCustomer, searchCustomers, clearCache };
  }
};
 
registry.category('services').add('customerService', customerService);

7.2 Consuming the Custom Service in a Component

import { Component, onWillStart, useState } from '@odoo/owl';
import { useService } from '@web/core/utils/hooks';
 
export class CustomerCard extends Component {
  static template = 'my_module.CustomerCard';
 
  setup() {
    this.customerService = useService('customerService');
    this.state = useState({ customer: null, loading: true });
 
    onWillStart(async () => {
      this.state.customer = await this.customerService.getCustomer(
        this.props.partnerId
      );
      this.state.loading = false;
    });
  }
}

7.3 Service with Shared State

Services are ideal for managing shared application state. Here's a cart service pattern for a POS-style module:

const cartService = {
  dependencies: ['notification'],
 
  start(env, { notification }) {
    const items = [];
    const listeners = new Set();
 
    function notify() {
      listeners.forEach(fn => fn([...items]));
    }
 
    return {
      addItem(product) {
        const existing = items.find(i => i.id === product.id);
        if (existing) {
          existing.qty++;
        } else {
          items.push({ ...product, qty: 1 });
        }
        notify();
        notification.add(`${product.name} added to cart`, { type: 'info' });
      },
      removeItem(productId) {
        const idx = items.findIndex(i => i.id === productId);
        if (idx !== -1) items.splice(idx, 1);
        notify();
      },
      getItems: () => [...items],
      subscribe: (fn) => { listeners.add(fn); return () => listeners.delete(fn); },
      getTotal: () => items.reduce((sum, i) => sum + i.price * i.qty, 0),
    };
  }
};
 
registry.category('services').add('cartService', cartService);

8.1 How Legacy Odoo JS Handled Shared Logic

Before OWL, Odoo's JavaScript used a widget system built on Backbone-like patterns. Shared logic was handled through:

• Global session objects (odoo.session_info, odoo.web.session)
• Prototype-based mixins that were manually composed into widget classes
• Direct calls to ajax.jsonRpc() or rpc() helper functions imported ad hoc
• Event-based communication through a global event bus with loosely typed event names

This worked for simpler applications, but it didn't scale. Mixins created deep inheritance chains that were impossible to reason about. Global state scattered across session objects made testing a nightmare. There was no concept of dependency injection — you either imported a utility directly or found a reference through the global scope.

8.2 OWL 1 Improvements

OWL 1 introduced a proper service architecture, but it was still finding its footing:

• Services were registered and consumed via useService() — clean DI for the first time
• Components had a proper lifecycle (setup, onMounted, onWillUnmount)
• The OWL environment (env) became the primary way to share context
• The registry pattern centralized service registration

But OWL 1 also had rough edges. Some core services were still tightly coupled to their implementation. The rpc service, for example, was consumed via useService('rpc') inside components, which mixed concern — a component accessing the network layer directly through a service hook.

8.3 OWL 2 Architecture Improvements

OWL 2 (Odoo 18+) made several architectural improvements that reflect a more mature understanding of frontend engineering:

• Core services like rpc became importable ES modules — cleaner and more tree-shakeable
• The useService hook became reserved for true singleton services requiring OWL lifecycle integration
• Async patterns became more predictable — pending calls are safely discarded on component destroy
• Service testing and mocking became first-class: HOOT's testing utilities make it easy to stub services
• The separation between application environment (env) and service instances became cleaner

Structure Services for Enterprise Scale

In large projects, organize services by domain:

// Good service organization for a large project
registry.category('services').add('sale.customerService', customerService);
registry.category('services').add('sale.orderService', orderService);
registry.category('services').add('inventory.warehouseService', warehouseService);
registry.category('services').add('pos.sessionService', posSessionService);

Using useService Outside of setup()

The useService hook must be called inside a component's setup() function — not in event handlers, not in onWillStart callbacks, not in utility functions. This is a hard OWL constraint. Violating it causes hooks to be registered outside the component lifecycle, leading to subtle bugs.

// ❌ WRONG — useService called outside setup
async handleClick() {
  const orm = useService('orm'); // This will error
  await orm.create('sale.order', {});
}
 
// ✅ CORRECT — useService called in setup, used in handler
setup() {
  this.orm = useService('orm');
}
 
async handleClick() {
  await this.orm.create('sale.order', {});
}

13.1 Notification Service in Sales Workflow

A sales module component that saves a quotation and notifies the user:

setup() {
  this.orm = useService('orm');
  this.notification = useService('notification');
  this.action = useService('action');
}
 
async confirmQuotation() {
  try {
    await this.orm.call('sale.order', 'action_confirm', [[this.props.orderId]]);
    this.notification.add('Quotation confirmed!', { type: 'success' });
    this.effect.add({ type: 'rainbow_man', message: 'Order confirmed!' });
    await this.action.doAction('sale.action_quotations_with_onboarding');
  } catch (err) {
    this.notification.add('Failed to confirm quotation', { type: 'danger' });
  }
}

13.2 ORM Service for Customer Dashboard

Fetching and displaying customer analytics using the ORM service:

setup() {
  this.orm = useService('orm');
  this.state = useState({
    topCustomers: [],
    totalRevenue: 0,
    loading: true,
  });
 
  onWillStart(async () => {
    const orders = await this.orm.searchRead(
      'sale.order',
      [['state', '=', 'sale']],
      ['partner_id', 'amount_total'],
      { limit: 100, order: 'amount_total desc' }
    );
 
    this.state.topCustomers = orders.slice(0, 10);
    this.state.totalRevenue = orders.reduce((sum, o) => sum + o.amount_total, 0);
    this.state.loading = false;
  });
}

13.3 Dialog Service for Delete Confirmation

async deleteRecord(recordId) {
  return new Promise((resolve) => {
    this.dialog.add(ConfirmationDialog, {
      title: 'Delete Product',
      body: 'This action cannot be undone. Continue?',
      confirm: async () => {
        await this.orm.unlink('product.template', [recordId]);
        this.notification.add('Product deleted', { type: 'info' });
        resolve(true);
      },
      cancel: () => resolve(false),
    });
  });
}