On-behalf-of submissions are legal requests filed by one person for another, such as an executive assistant submitting a contract review for a vice president or a coordinator raising an NDA for a sales lead. The intake platform has to record both people: the submitter who filled in the form and the beneficiary who owns the business need. Get that distinction right, and routing, updates, and contract ownership all follow the correct person. Get it wrong, and legal chases the assistant for answers only the executive can give.
What are on-behalf-of submissions in legal intake?
On-behalf-of submissions in legal intake are requests where the person completing the form differs from the person the legal service is for, and the platform stores the two as separate roles on the request. The submitter starts the record, and the beneficiary owns the need, answers substantive questions, and usually receives the outcome.
Most intake platforms support both paths: submitting for yourself or for another employee. The design question is what each role does afterward. A request that records only the submitter treats the assistant as the business owner, which breaks routing, reporting, and every notification that follows. A clear legal service request intake design accounts for this from the first screen, and many teams still lack one: a 2025 survey of in-house legal teams found over 76 percent of legal departments still rely on manual processes to manage their legal matters.
Why do legal teams need to separate submitter and beneficiary?
Legal teams need to separate submitter and beneficiary because the two people hold different information and different responsibilities. The submitter often knows the logistics, and the beneficiary knows the business context, the risk, and whether the deal should proceed.
- Assistants and coordinators. An executive assistant may file for five to ten executives. Reporting that credits every request to the assistant hides which business leaders actually generate legal demand. Demand data is exactly what legal operations wants more of: in a 2025 survey of 188 companies, business intelligence as an area to address rose from 58 to 65 percent.
- Contract relationship owners. The person who submits a contract request may not manage the relationship. Renewal and expiry notices must reach the owner, or deadlines pass unnoticed.
- Managers filing for teams. A manager raising an employment question for a team member needs the request routed by that employee’s country and department. The manager’s own profile is irrelevant to the legal work.
Without the split, legal ends up asking basic questions twice and sending decisions to people who cannot act on them. Reporting suffers as well, since demand by department and business unit is only accurate when each request carries the beneficiary’s details.
What roles should an on-behalf-of request record?
An on-behalf-of request should record at least two business roles, the submitter and the beneficiary or primary business contact, alongside the legal assignee who handles the work. Each role has its own responsibilities and access.
- Submitter. Initiates the request, can view status, respond to information requests, and receive updates.
- Beneficiary or primary business contact. Owns the business need or contract relationship, provides substantive information, and receives decisions and lifecycle notices.
- Legal assignee. Reviews, triages, and resolves the request, with supervisors and administrators holding oversight and configuration rights.
Use consistent role labels across every request type, so reports and notification rules can rely on them.
How should the intake form ask who a request is for?
The intake form should ask who a request is for as its first question, with two plain options: for myself, or for someone else. Choosing “someone else” reveals a person picker linked to the employee directory.
- Directory lookup. Select the beneficiary by name from the directory, which fills their email, department, and country automatically and avoids typing errors.
- Same category forms. After the beneficiary is chosen, show the same category-specific questions as a direct submission. Only the people change.
- Confirmation step. Before submission, show both names side by side with a line such as “You are submitting this for Maria Lopez.” It catches most picker mistakes, which are otherwise found only when the wrong person starts receiving updates.
Keep the wording short and clear. Legal intake form best practices for enterprises apply here as everywhere, and a confusing first question pushes people back to email.
Whose profile data should drive routing on an on-behalf-of request?
The beneficiary’s profile data should drive routing on an on-behalf-of request, since the legal work concerns their department, business unit, country, and legal entity. The submitter’s profile should be recorded but left unchanged.
A contract request filed by a UK-based assistant for a German sales director, for example, should route by the director’s entity and region to the right commercial team. Where forms prefill or update user profile fields, make sure edits made for the beneficiary never overwrite the submitter’s own details, and confirm this behavior in your platform during testing.
Routing rules then work exactly as they do for direct requests, and legal request triage sees the correct business context.
Who should receive notifications on an on-behalf-of request?
Both the submitter and the beneficiary should receive notifications on an on-behalf-of request, with the content matched to each role. Some platforms, including ServiceNow Legal Request Management, send updates to both users and let either one update the request when legal asks for more information.
- Shared updates. Acknowledgment, requests for information, assignment, decision, and closure go to both people, so neither has to forward messages.
- Role-specific notices. Lifecycle notices, such as contract renewal or expiry reminders, go to the beneficiary or primary business contact, with the submitter copied only where your process requires it.
- Documented rules. Decide the rule per notification type, and document it.
Unclear rules usually end with executives missing decisions or assistants flooded with notices they cannot act on.
What should each participant be able to see and do?
Each participant on an on-behalf-of request should see the request status and shared comments, and both business users should be able to answer information requests. Internal legal notes stay visible to legal only.
- Business users. Submitter and beneficiary can view status, add comments, upload documents, and reply to information requests.
- Request lists. The request should appear in both people’s “my requests” view, so neither assumes it was lost.
- Sensitive categories. For employment, investigations, or other sensitive matters, limit what the submitter sees, or route those categories through self-submission only.
Visibility for on-behalf-of requests is easy to get wrong. A request that disappears from the submitter’s or beneficiary’s list generates duplicate submissions within days, so test it explicitly.
What happens when an on-behalf-of request becomes a matter or contract?
When an on-behalf-of request becomes a matter or contract, both roles should carry into the new record, with the beneficiary set as the business owner or primary business contact. The link to the original request should stay intact.
On a contract, the primary business contact receives renewal, expiry, and obligation notices through every stage of the contract lifecycle, long after the submitter has moved on. On a matter, the beneficiary joins as the business client, and the submitter can be added as a participant where they will keep supporting the work.
Confirm how your platform transfers roles into downstream matter and contract records, since this varies by configuration.
How do you test on-behalf-of submissions before go-live?
On-behalf-of submissions are tested by running every request category through both paths, self and on behalf, and checking routing, alerts, visibility, and downstream records for each participant. A typical plan covers 15 to 25 scenarios.
- Routing and profile checks. Confirm routing follows the beneficiary’s profile, and that the submitter’s profile is unchanged after submission.
- Notification checks. Trigger acknowledgment, information requests, decisions, and closure, and confirm each reaches the right people with the right content.
- Visibility and security checks. Confirm the request appears in both users’ lists, internal notes stay hidden, and sensitive categories behave as designed.
Treat these as role-based tests, since skipping role-based security testing leads to chaotic go-lives.
Conclusion
On-behalf-of submissions work when the platform treats the submitter and the beneficiary as two distinct people with distinct jobs. Ask who the request is for up front, route on the beneficiary’s profile, protect the submitter’s own data, keep both informed with the right content, give both the right visibility, and carry the correct owner into matters and contracts. Test each path, and requests filed for someone else will move as smoothly as any other.
How Basla can help
Basla provides delivery teams for legal intake and request management software implementation, covering the design of on-behalf-of submissions, requester and beneficiary roles, routing rules, alert configuration, visibility testing, documentation, and hypercare. Across its legal technology services, Basla teams have built a legal service request implementation with eight front doors for language and country variations, with every request carrying the right business contact into downstream records.
Frequently asked questions
What are on-behalf-of submissions?
On-behalf-of submissions are legal requests filed by one person for another, such as an assistant submitting for an executive. The platform records both the submitter and the beneficiary as separate roles on the request.
Can an employee submit a legal request for someone else?
Most legal intake platforms let an employee submit a request for themselves or for another employee. The form should ask who the request is for and let the submitter pick the beneficiary from the directory.
Whose details should route an on-behalf-of legal request?
The beneficiary’s department, country, business unit, and legal entity should route an on-behalf-of legal request, since the legal work concerns them. The submitter’s profile should be recorded but not changed.
Who gets notified on a request submitted for someone else?
Both the submitter and the beneficiary should receive shared updates such as acknowledgment, information requests, and decisions. Lifecycle notices, such as contract renewals, go to the beneficiary or primary business contact.
Can both people update an on-behalf-of request?
Both the submitter and the beneficiary should be able to answer information requests, add comments, and upload documents, subject to the organization’s permissions for sensitive categories.
What is a primary business contact on a legal request?
A primary business contact is the person who owns the business need or contract relationship behind a legal request. They receive decisions and lifecycle notices, even when someone else submitted the request.
*This article is provided for general information only and does not constitute legal advice. Basla Solutions provides legal technology implementation and support services and does not practice law.*