We’re designing API-driven extensions for our Epicor SCM 10.2.500 distribution management implementation and debating the best approach for data model extensions.
The question: Should we use Epicor’s built-in User-Defined Fields (UDFs) or implement custom fields in our own database tables?
Our requirements:
- Need to store additional customer attributes (loyalty tier, credit score, preferred shipping method)
- Must be accessible via REST API for mobile app and partner integrations
- Should support reporting and analytics
- Need to survive Epicor upgrades with minimal rework
I’ve heard arguments both ways. UDFs seem simpler but I’m concerned about API accessibility and reporting limitations. Custom fields give more control but potentially complicate upgrades.
What’s the community consensus on custom field vs UDF comparison for API-driven scenarios? How do upgrade and reporting impacts differ between these approaches?
That’s a good point about field naming. How do you handle that in practice? Do you build a mapping service, or just document the UDF field mappings for API consumers?
Also, what about reporting? Can UDFs be easily included in standard Epicor reports, or do they require custom report development?
UDFs are definitely the path of least resistance. They’re automatically included in Epicor’s standard APIs and show up in the UI without customization. For your use case - customer attributes - UDFs would work perfectly.
The main limitation is field types. UDFs support string, number, date, and checkbox. If you need complex data structures or relationships, you’d need custom tables. For simple attributes like loyalty tier or preferred shipping method, UDFs are ideal.
From an upgrade perspective, UDFs are much safer. They’re stored in Epicor’s data dictionary and migrate automatically during version upgrades. Custom tables require manual migration scripts and testing.
That said, UDFs have a fixed limit (usually 20-30 per table depending on version). If you anticipate needing many custom attributes or frequent schema changes, custom tables provide more flexibility. But you pay for that flexibility with upgrade complexity.