In Salesforce Field Service, Work Order Line Items (WOLIs) are child records of Work Orders in a master-detail relationship. When users attempt to edit or delete WOLI records, Salesforce enforces permissions based on the parent Work Order object, not the WOLI object itself. This can create confusion when users appear to have delete capability in certain interfaces but are unable to perform the action, or vice versa.
- You can delete WOLI records despite lacking explicit delete permission on the WOLI object.
- You cannot delete WOLI records even though you have delete permission on the WOLI object.
- Delete options appear in the user interface (Lightning Experience, mobile browser, partner community) but the action fails or is not available.
- Permission settings on the WOLI object or sharing rules do not prevent or allow WOLI deletion as expected.
Work Order Line Item is a standard Salesforce object with a master-detail relationship to the Work Order object. Due to this relationship, object-level permissions such as Create, Edit, and Delete cannot be configured directly on the WOLI object. Instead, these permissions are inherited from the parent Work Order object.
When a user attempts to edit or delete a WOLI record, Salesforce evaluates the user's Edit permission on the parent Work Order. If the user has Edit permission on the Work Order, they can edit and delete WOLIs. If they lack Edit permission on the Work Order, they cannot perform these actions on WOLIs—regardless of any sharing rules or field-level security settings applied to the WOLI itself.
This behavior applies across all access contexts, including partner communities and mobile browsers.
To restrict users from deleting WOLI records, remove the Edit permission on the Work Order object for those users.
Steps
1. Navigate to Setup → Profiles (or Permission Sets if using permission set-based access control).
2. Select the profile or permission set assigned to the user who should not delete WOLIs.
3. Scroll to the Standard Object Permissions section and locate Work Order.
4. Uncheck the Edit checkbox for the Work Order object.
5. Save the changes.
Removing Edit permission on the Work Order will prevent users from editing Work Order records themselves, not just deleting WOLIs. Carefully evaluate the business impact before making this change. If you need users to edit Work Orders but not delete WOLIs, consider implementing a trigger-based workaround to enforce WOLI-specific delete restrictions.
- WOLI permissions cannot be configured independently from the parent Work Order object. There is no WOLI-specific Edit or Delete permission setting.
- Sharing rules and field-level security on WOLI do not override the parent Work Order's Edit permission requirement.
- This behavior is consistent across all Salesforce interfaces, including Lightning Experience, Salesforce Field Service mobile app, and partner communities.
- If your business requires granular WOLI delete restrictions (e.g., allow editing but deny deletion), you must implement a custom Apex trigger or Flow to enforce the restriction.
Cause
Work Order Line Item (WOLI) is a standard Salesforce object with a master-detail relationship to the Work Order object. Due to this relationship, object-level permissions such as Create, Edit, and Delete cannot be configured directly on the WOLI object. Instead, these permissions are inherited from the parent Work Order object.
When a user attempts to edit or delete a WOLI record, Salesforce evaluates the user's Edit permission on the parent Work Order. If the user has Edit permission on the Work Order, they can edit and delete WOLIs. If they lack Edit permission on the Work Order, they cannot perform these actions on WOLIs—regardless of any sharing rules or field-level security settings applied to the WOLI itself.
This behavior applies across all access contexts, including partner communities and mobile browsers.
Help Article about WOLI permission inheritants:
https://help.salesforce.com/s/articleView?id=sf.fs_wo_settings.htm&type=5
005386959

We use three kinds of cookies on our websites: required, functional, and advertising. You can choose whether functional and advertising cookies apply. Click on the different cookie categories to find out more about each category and to change the default settings.
Privacy Statement
Required cookies are necessary for basic website functionality. Some examples include: session cookies needed to transmit the website, authentication cookies, and security cookies.
Functional cookies enhance functions, performance, and services on the website. Some examples include: cookies used to analyze site traffic, cookies used for market research, and cookies used to display advertising that is not directed to a particular individual.
Advertising cookies track activity across websites in order to understand a viewer’s interests, and direct them specific marketing. Some examples include: cookies used for remarketing, or interest-based advertising.