Introduction
If you have ever saved a form in Odoo and seen a field turn red, you have already encountered the required field mechanism. It is one of the most fundamental features in the Odoo data model, and one of the simplest ways to enforce data quality across your business workflows.
Whether you are configuring Odoo for a sales team, setting up a custom model, or working on a technical odoo development project, understanding how the required attribute works will help you build more reliable processes.
This guide covers everything: how the field behaves in the odoo framework, how to configure it using Odoo Studio or Python code, when to use it, and what mistakes to watch out for.
What Is the Required Field in Odoo
In Odoo, the required attribute is a field-level constraint that prevents a record from being saved unless the field contains a value. It applies to virtually all odoo field types: text fields, numeric fields, selection fields, many2one fields, dates, and more.
It is part of the core odoo data model and is one of the most commonly used attributes when doing odoo customization. Setting a field as required is the first line of defense against incomplete or inconsistent data in your database.
How It Appears in the Interface
In the Odoo UI, required fields are visually distinguished from optional ones. When a form is in edit mode, required fields typically display a subtle visual indicator. When a user tries to save the record without filling in a required field, Odoo highlights the field in red and displays a warning message.
This behavior is consistent across the web interface. Users see immediate, clear feedback, which reduces the chance of submitting incomplete records.
Static vs. Dynamic Required
There are two ways to make a field required in Odoo. The first is a static required: the field is always mandatory, no matter what. The second is a dynamic required: the field becomes mandatory only when certain conditions are met, based on the values of other fields on the same record.
Both approaches are used regularly in odoo development. The choice depends on your business logic.
How the Field Works
Understanding how the required attribute works at a technical level helps you apply it correctly and debug issues when they come up.
Application-Level Enforcement
An important detail that surprises many Odoo users: the required attribute is enforced at the application level, not at the database level. This means the constraint is checked by the Odoo ORM when a record is created or written, before the data reaches the database.
There is no NOT NULL constraint added to the underlying PostgreSQL column by default when you set required=True on a field. The validation happens in Python, inside the odoo orm layer.
In practice, this means that data inserted directly into the database (bypassing Odoo) will not be caught by the required constraint. Always interact with your Odoo odoo database fields through the ORM or the API to benefit from this protection.
What Happens When the Constraint Is Violated
When a user tries to save a form with a required field left empty, two things happen:
- The field turns red in the interface, and Odoo shows a validation message
- The save operation is blocked until the field is filled in
If you trigger the validation programmatically (for example, via the XML-RPC API or a server action), Odoo raises a ValidationError with a message indicating which required field is missing.
Dynamic Required Using Domains
In the odoo framework, the required attribute can be made conditional using view-level expressions. In Odoo 16 and earlier, this is done with the attrs attribute in the view XML:
<field name="x_delivery_date" attrs="{'required': [('order_type', '=', 'delivery')]}" />In Odoo 17 and later, the syntax is simplified with a direct required expression on the field tag in the view:
<field name="x_delivery_date" required="order_type == 'delivery'" />These conditional rules live in the view layer, not the model layer. This is an important distinction: the model-level required=True always enforces the constraint, while view-level expressions only apply in specific interface contexts.
Interaction with the ORM and API
In the odoo orm, when you call create() or write() on a model, the ORM checks all fields with required=True before executing the database operation. If a required field is missing or set to False, Odoo raises a ValidationError.
This also applies when creating records via the XML-RPC API. Any field marked as required in the model definition must be provided in the data dictionary passed to the create method, or the call will fail with an error.
Business Use Cases
Required fields appear throughout standard Odoo, and they are equally useful in custom configurations. Here are five concrete examples from real business workflows where making a field required makes a genuine difference.
1. CRM: Customer Segment Required on Leads
A sales team wants to ensure every lead is assigned to a customer segment before it is moved to the pipeline. Without a required field, sales reps often skip this step, making it impossible to report on lead sources by segment later.
By marking a custom "Customer Segment" selection field as required on the CRM lead form, the team ensures the data is always captured at the point of entry. No segment, no save.
2. Sales: Delivery Address Required on Orders
For companies that ship physical goods, the delivery address is critical. In some Odoo configurations, the delivery address field is not required by default, which means orders can be confirmed without one.
Making the delivery address field required on the sales order form prevents the order from being confirmed before the logistics team has the information they need. This eliminates a common source of errors in the fulfillment process.
3. Inventory: Lot or Serial Number Required at Reception
For companies operating in regulated industries (food, pharmaceuticals, electronics), tracking lot numbers on received goods is not optional. Odoo supports this natively through the tracking setting on products, which effectively enforces a required lot or serial number during stock moves.
For custom fields on receipt forms, like a quality control reference, making the field required ensures the warehouse team never forgets to log the information during the reception process.
4. Accounting: Cost Center Required on Vendor Bills
Finance teams often need every expense to be assigned to a cost center for budget tracking. Without enforcement, accountants or purchasing managers may leave the field blank, creating gaps in financial reporting.
A required many2one field pointing to the cost center model, added to the vendor bill form, ensures that no bill can be posted without this assignment. This kind of odoo customization is quick to implement and has a direct impact on data completeness.
5. HR: Contract Type Required Before Onboarding
HR teams managing employee onboarding in Odoo often want to ensure the contract type is recorded before the employee record is finalized. A required field on the employee form prevents the HR team from inadvertently saving an incomplete employee record during a busy onboarding period.
Creating or Customizing the Field
There are two main ways to mark a field as required in Odoo: using Odoo Studio for a no-code approach, or writing Python code for full control. Both are valid depending on your context.
Using Odoo Studio
Odoo Studio is the built-in no-code tool that lets you configure fields without any development. When you open Studio and select a field on a form, you will see a "Required" toggle in the field properties panel on the right.
Enabling this toggle marks the field as required in the view and stores the constraint at the model level. This is the fastest approach for simple cases and requires no technical knowledge. It works well for both standard Odoo fields and custom fields added through odoo studio fields.
The limitation of Studio is that it only configures a static required constraint. For dynamic required behavior based on other field values, you need to edit the view XML directly or use the technical approach.
Technical Approach: Python Fields
In a custom Odoo module, declaring a required field is as simple as adding required=True to the field definition. This is the standard pattern in odoo python fields development:
from odoo import fields, models
class SaleOrder(models.Model):
_inherit = 'sale.order'
x_customer_segment = fields.Selection(
selection=[
('smb', 'SMB'),
('enterprise', 'Enterprise'),
('public', 'Public Sector'),
],
string='Customer Segment',
required=True,
)
x_cost_center_id = fields.Many2one(
comodel_name='account.analytic.account',
string='Cost Center',
required=True,
)With this approach, the constraint is enforced at the model level, meaning it applies regardless of which view or interface is used to create the record. It cannot be bypassed by accessing the record through a different view.
Dynamic Required in View XML
When the required constraint should only apply under certain conditions, add it at the view level rather than the model level. In Odoo 16:
<field name="x_cost_center_id"
attrs="{'required': [('order_type', '=', 'invoiced')]}" />In Odoo 17:
<field name="x_cost_center_id"
required="order_type == 'invoiced'" />This is a view-only constraint. It is less strict than a model-level required, since it only applies when the record is edited through the specific view containing this definition.
Creating Required Fields via the API
If you use the XML-RPC API to create fields (as covered in other articles in the Odoo Data & API collection), you can set required when calling create on ir.model.fields. This is part of the standard odoo developer guide for programmatic customization:
models.execute_kw(ODOO_DB, uid, ODOO_API_KEY,
'ir.model.fields', 'create',
[{
'name': 'x_customer_segment',
'field_description': 'Customer Segment',
'model_id': model_id,
'ttype': 'selection',
'selection': "[('smb', 'SMB'), ('enterprise', 'Enterprise')]",
'required': True,
'state': 'manual',
}]
)This creates the field and enforces the required constraint in one step, which is useful in automated deployment workflows for create fields odoo scenarios.
Best Practices
Marking a field as required seems straightforward, but using it well takes some thought. Here are the practices that will save you time and prevent frustration for your users.
1. Only Make Fields Required When They Genuinely Are
Over-requiring fields is one of the most common Odoo configuration mistakes. If a user cannot complete a form because a field is required but the information is not yet available, they will find workarounds (like entering placeholder values) that corrupt your data.
Before marking a field as required, ask: is this information always available at the point of entry? If the answer is not a clear yes, consider making it required at a later stage (for example, at confirmation rather than at creation) or use a dynamic required instead.
2. Use Stage-Based Validation Instead of Always-Required
For workflows with multiple steps, like a CRM opportunity or a manufacturing order, it is often better to enforce required fields at specific stages rather than from the start. This is typically done through Python constraints or automated actions that check field values when the record moves to a given stage.
This pattern is more flexible and user-friendly than making every field required from day one.
3. Pair Required Fields with Default Values Where Sensible
If a field is required and has a sensible default value for most cases, set a default on the field definition. This reduces friction for users who do not need to change the default, while still ensuring the field is never empty.
4. Prefer Model-Level Required for Critical Data
For data that is genuinely critical (like accounting information, regulatory identifiers, or mandatory identifiers), enforce the constraint at the model level in Python rather than only at the view level. View-level required constraints can be bypassed if a record is created through the API or a different view that does not include the constraint.
5. Communicate Required Fields to End Users
When you add new required fields to existing forms, users who are mid-workflow may be surprised. Communicate changes to your team before deploying, especially if existing records might fail validation on the next edit.
6. Test with Empty and Partial Data
Before deploying a configuration with new required fields, always test the full workflow with empty values and partial data. This includes testing via the web interface, via the API, and via any automated actions or integrations that create records in Odoo. This is a basic step in any responsible odoo technical tutorial.
Common Pitfalls
Even experienced Odoo implementers run into issues with required fields. Knowing what to watch for will save debugging time and prevent painful rollbacks.
Pitfall 1: Making a Field Required on a Model That Already Has Records
If you add required=True to a field on a model that already contains thousands of records, and those records do not have a value for that field, you may hit issues when those records are next edited. Users will be unable to save any changes until they fill in the newly required field.
Before deploying a required constraint on an existing field, always check whether existing records already have values. If they do not, run a data migration to populate the field first.
Pitfall 2: Confusing View-Level and Model-Level Required
Setting a field as required in a view (whether through Studio or view XML) does not enforce the constraint at the model level. A record created through the API, a different view, or an import will bypass view-level required constraints entirely.
If you need a hard constraint, set required=True in the Python field definition. This is a frequently misunderstood point in the odoo field tutorial community, and it causes real data quality issues in production.
Pitfall 3: Required Fields in Automated or Scheduled Actions
When an automated action or scheduled action creates records programmatically, it must provide values for all required fields. If the action was written before a required field was added, it will start failing silently or with a cryptic error after the required constraint is deployed.
Always review all automated record creation code after adding a required field to an existing model.
Pitfall 4: Importing Data That Misses Required Fields
When importing records via CSV or the Odoo import tool, required fields that are missing from the import file will cause the import to fail. This is actually the correct behavior, but it surprises users who are used to importing partial data.
Always include all required fields in your import templates. It is good practice to document which fields are required in your data import guidelines.
Pitfall 5: Using Required Instead of a Python Constraint for Complex Validation
The required attribute only checks that a field is not empty. It does not validate the content or the relationship between fields. For more complex validation (for example, ensuring a date is in the future, or that two fields are consistent), use a @api.constrains decorator in Python instead.
Trying to encode business logic into required fields alone leads to inflexible configurations that are hard to maintain.
Conclusion
The required field attribute is one of the simplest tools in Odoo, but it has a real impact on the quality of your data. Used well, it ensures that critical information is always captured at the right moment in your business processes. Used poorly, it frustrates users and creates workarounds that make your data less reliable, not more.
The key is to understand the difference between model-level and view-level required constraints, to be deliberate about which fields genuinely need enforcement, and to think ahead about how the constraint will behave in automated workflows and API integrations.
Whether you are following an odoo developer guide, doing a full odoo customization project, or just adjusting a form in Odoo Studio, the required attribute is worth understanding deeply. It is one of those details that separates a clean Odoo implementation from one that causes headaches six months after go-live.
Need Help with Your Odoo Implementation?
At Dasolo, we help companies implement, customize, and optimize Odoo across all business functions and levels of complexity. Whether you need help designing a solid data model, configuring validation rules, or building custom modules, our team brings both technical and functional expertise to every project.
If you have questions about required fields or any other aspect of your Odoo setup, we are happy to help. Reach out to us and let's talk about what you are building.