Short answer: the question is not “can I create a field?” but “where does that field exist afterwards?”. A field that shows on a record but cannot be filtered, exported or used in a business rule is not a custom field, it is a comment with a label on it. The difference can be measured in a demo, in six questions.
What is a custom field?
A custom field is a piece of data you add yourself to an entity in the software (a project, a client, a person, an invoice) and which the system then treats exactly like its own native fields: typed, filterable, exportable, usable in rules and available through the API.
The important word is afterwards. Creating the field is the easy half, and it is the half every demo shows you.
Why a free-text note is not enough
The classic workaround is to put the missing information in a “notes” field. It works for a few months, then it starts costing:
- you cannot sort or filter free text filled in by twelve different people;
- the data does not exist in exports, so it gets re-keyed by hand into a spreadsheet;
- no rule and no alert can be built on it;
- the values drift (“confidential”, “Confidential”, “CONF.”) and analysis becomes impossible;
- nobody knows whether the field is up to date, so nobody relies on it.
The cost never shows up in a budget. It shows up in the hours spent rebuilding the information in Excel.
The six questions to ask in a demo
Have a field created in front of you, then ask these in order:
- Which entities can I add one to? A tool that only allows fields on projects will block you the day the need is about people.
- Which types are available? Text, number, date, value list, yes/no. A closed list beats free text anywhere the analysis matters.
- Can I make it mandatory? An optional field is an empty field on half the records, and an analysis over half the records is not an analysis.
- Does it appear in the report builder? Ask for it to be added as a column and as a filter, right there, during the demo.
- Does it come out in exports and in the API? That is what decides whether your BI and your other tools can use it.
- Can I use it in a rule or an alert? This is the highest step, and the one that separates a real field from a decorative one.
If the answers to questions 4, 5 and 6 are “not yet” or “through a development”, you are not buying a configurable product.
Custom field or tag: which one?
Both describe what the standard product does not, but they answer different questions.
| Custom field | Tag | |
|---|---|---|
| Used for | Carrying data specific to one record | Classifying along a shared axis |
| Example | Framework number, clearance level | Business unit, contract model |
| Values | Free or listed | A short, closed list |
| Typical use | Reporting, export, rules | Grouping and comparison |
| Watch out for | Staying filterable | Keeping the history of changes |
As a rule of thumb: if you intend to group by this information, it is a tag, and you then need to check it is historised. If you intend to read it or pass it on, it is a field.
What if the field needs development?
It happens, and an honest vendor tells you before you commit. The dividing line is usually simple: adding a piece of data and making it travel is configuration, whereas a new behaviour of the product (a calculation, a control, an integration) is development. What matters is knowing which side you are on before signing, with a timeline and, where relevant, a quote.
In practice
In AlibeeZ, a field added from the admin area turns up in the screens, the reports and dashboards, the API, the Excel and CSV exports, and your custom rules. The whole journey, from missing field to field available everywhere, is illustrated on the customisation page, along with the option of trying it on a test base before it reaches production.
Frequently asked questions
What is a custom field in an ERP?
It is a piece of data you add yourself to an entity in the software (project, client, person, invoice) and which the system then treats like its native fields: typed, filterable, exportable, usable in rules and available through the API.
What is the difference between a custom field and a notes field?
A notes field holds free text: it cannot be filtered, no rule can be built on it, and it does not come out cleanly in exports. A real custom field is typed and travels through the whole product, which is what makes it usable.
Should I use a custom field or a tag?
If you intend to group your analysis by this information, it is a tag, and you need to check that it is historised. If you intend to read it, export it or pass it to another tool, it is a custom field.
Does adding a custom field require development?
Usually not: adding data and making it travel is configuration. Development becomes necessary when the need is about a new behaviour of the product: a calculation, a control or an integration.
