Acumatica Employee Self-Service — Extension Patterns

Employee self-service in Acumatica covers time entry, expense claims, and requests submitted by employees who typically don't have a full ERP license — which changes the shape of the extension work: it's as much about approval routing and a constrained UI as it is about the underlying data model.

Core DACs and screens

The employee record is EPEmployee, tied to the shared Contact/BAccount structure. Self-service screens for time cards and expense claims sit under the Employee Portal / Time and Expenses area, and approvals route through the same Approval Maps engine used elsewhere, with an assignment map typically keyed on the employee's manager or department. The graph most self-service customizations touch is the employee maintenance graph, EmployeeMaint, plus whichever entry graph backs the specific self-service screen (time card, expense claim) being customized.

Extension points

Because self-service users have restricted licenses, extensions here need to respect what fields and actions are actually exposed to that role — a customization that adds a field only visible to full-access users but expects self-service employees to populate it will silently fail to collect the data it needs. Field-level and screen-level access rights (via the Access Rights by Screen configuration) need to be checked as part of any self-service customization, not just the DAC/graph layer.

A realistic scenario: manager delegation

A common EP customization: allow an employee to submit a request (time off, expense) that routes to a delegate approver when their regular manager is out, since the stock approval map is normally keyed to a single manager assignment.

public class EmployeeMaint_Delegation_Extension : PXGraphExtension<EmployeeMaint>
{
    #region EPEmployeeExt
    public class EPEmployeeExt : PXCacheExtension<EPEmployee>
    {
        [PXDBInt]
        [PXSelector(typeof(Search<EPEmployee.employeeID>))]
        public int? DelegateApproverID { get; set; }
        public abstract class delegateApproverID : PX.Data.BQL.BqlInt.Field<delegateApproverID> { }
    }
    #endregion

    public virtual int? ResolveApprover(EPEmployee employee)
    {
        var ext = PXCache<EPEmployee>.GetExtension<EPEmployeeExt>(employee);
        bool delegateActive = ext?.DelegateApproverID != null
            && IsDelegationWindowActive(employee.EmployeeID);
        return delegateActive ? ext.DelegateApproverID : employee.SupervisorID;
    }
}

The exact approval-routing hook point depends on how the Approval Maps engine resolves the assignee for a given map — in most versions this means implementing an assignment rule that calls out to logic like the above rather than hardcoding delegation into each request's entry graph individually.

Mobile and portal considerations

Self-service screens are frequently accessed through the mobile app or a simplified portal view, and a field or validation added to the desktop screen doesn't automatically show up there — mobile screen layouts are configured somewhat separately. If a self-service customization needs to work on mobile, verify it explicitly rather than assuming parity with the desktop UI.

Testing considerations

Test as an actual restricted employee-portal user, not as an administrator — the two roles see meaningfully different UI and have different access rights, and a customization that works perfectly when tested under an admin login is one of the most common and avoidable EP delivery mistakes.

Wrapping up

Employee self-service customization is less about data modeling and more about respecting the constrained role it serves — verify field visibility and access rights for the actual restricted user, and route approval changes through the assignment map's resolution logic rather than duplicating it per screen.