UDFs vs Custom DACs in Acumatica — When to Use Which

User-defined fields — added through the Customization Editor's UDF designer, no C# required — versus a hand-written PXCacheExtension in a Visual Studio project: I get asked which is "correct" often enough that it's worth writing down the actual tradeoffs, because the honest answer is "it depends on what the field needs to do," not "one is always better."

What the UDF designer actually generates

Adding a field through the Customization Editor's User-Defined Fields tool generates, under the hood, essentially the same thing you'd hand-write — a PXCacheExtension with a Usr-prefixed field, backed by attributes chosen from the designer's UI (data type, length, a subset of common attributes like required/default value). It's not a separate mechanism running in parallel with DAC extensions; it's a no-code UI generating the same underlying extension artifact, packaged inside the customization project without you writing or seeing the C#.

That matters for the decision: you're not choosing between two fundamentally different technologies. You're choosing between generating a DAC extension through a form, versus writing one by hand with full control.

Where the UDF designer is genuinely the right call

• Simple storage fields with no behavior — a text note, a reference number, a date, a checkbox with no validation logic attached. If the field is purely "store this value, show it on the screen," the designer does the whole job.
• Fields added by non-developers — a power user or admin with Customization Editor access, no Visual Studio, no deployment pipeline. This is a legitimate and common scenario, especially for smaller clients without a dedicated dev resource, and the UDF tool is specifically designed to make this self-service.
• Fast iteration during requirements discovery — adding a field via the designer to validate with a client "is this the field structure you actually need" before committing to a hand-written implementation, similar in spirit to prototyping in the browser Code Editor.

Where the UDF designer runs out of road

• Any real event-driven behavior. The designer can attach a default value and basic required/read-only state, but genuine business logic — a value computed from other fields, cross-field validation, an action triggered on change — needs a real event handler, which means a hand-written extension.
• Precision and attribute nuance. The designer's decimal/numeric options are a simplified subset of what PXDBDecimal, PXDefault, and friends actually support. If your field needs a specific PersistingCheck behavior or non-default rounding, you need the real attribute, not the designer's simplified form.
• Fields that need to participate in BQL queries written elsewhere — a UDF-generated field's abstract BQL field class is auto-generated and technically usable in BQL, but for a field you know will be referenced constantly across graph extensions, GIs, and reports, having it defined explicitly in a version-controlled DAC extension (with a clear, intentional name) is more maintainable than depending on generated naming from a designer.
• Testing and code review. A UDF lives inside the customization project, same storage/versioning limitations as the browser Code Editor discussed elsewhere — no unit tests, no diff-based code review, no IntelliSense for other developers referencing the field.

// What a UDF generates under the hood is structurally similar to
// this — but hand-writing it gives you the PersistingCheck control,
// the exact precision, and a place to add real event logic later
// without switching tools mid-project.
public sealed class CustomerExt : PXCacheExtension<Customer>
{
    public static bool IsActive() => true;

    [PXDBString(11, IsUnicode = true)]
    [PXDefault(PersistingCheck = PXPersistingCheck.Nothing)]
    [PXUIField(DisplayName = "KRA PIN")]
    public string UsrKRAPin { get; set; }
    public abstract class usrKRAPin : PX.Data.BQL.BqlString.Field<usrKRAPin> { }
}

The actual decision rule

If the field needs zero custom event logic and will be maintained by whoever's available (developer or admin), use the UDF designer — it's faster, it's self-service, and it's the same underlying mechanism anyway. The moment the field needs a FieldUpdated cascade, cross-field RowPersisting validation, or attribute precision the designer doesn't expose, write the PXCacheExtension by hand in a real Visual Studio project from the start, because retrofitting behavior onto a UDF-generated field later is possible but is friction you can avoid by making the right call up front.

Wrapping up

UDFs and hand-written DAC extensions aren't different technologies — the designer generates the same kind of PXCacheExtension you'd write by hand, through a form instead of code. Use the designer for simple storage fields and self-service scenarios; write the extension by hand the moment real event-driven behavior, precise attribute control, or serious code review and testing matter. And know that migrating from one to the other later is possible, just not something to assume you'll need until you actually do.