I’m trying to automate bulk status updates for employee goals using the Performance Management API but consistently getting 403 Forbidden errors. Our use case requires updating 200+ goals weekly from ‘In Progress’ to ‘Completed’ based on external system triggers.
I’ve verified my API user has RBP_PerformanceManagement role, but batch operations fail. Single goal updates work fine. The payload structure follows documentation:
POST /odata/v2/Goal/batch
[
{"goalId": "12345", "status": "2"},
{"goalId": "12346", "status": "2"}
]
Is there a specific permission requirement for bulk actions beyond standard goal management rights? Also wondering if proxy user configuration affects batch API calls differently than individual requests.
Adding to the RBP discussion - proxy users also need the ‘Access to Proxy as Another User’ permission in the API user’s role. This is under Admin Tools permissions. Without it, batch operations fail with 403 even if object-level permissions are correct.
The 403 on batch operations is almost always a proxy user permission issue. Standard API users need explicit batch operation rights even if they can do single updates. Check your proxy user mapping in Proxy Management - the batch endpoint requires ‘Manage Integration Tools’ permission.
Thanks for the feedback. I’ve added ‘Manage Integration Tools’ to the proxy user but still seeing 403s. The payload format makes sense - I was simplifying the actual OData batch structure. Are there any role-based permission templates specifically for bulk goal operations that I should check?
Great to hear you resolved it! Let me provide a complete solution summary for anyone facing similar issues with Performance Management API bulk operations.
Role-Based Permissions Requirements:
The key issue here is that bulk operations require THREE distinct permission layers:
-
Object-Level Permissions: In your API user’s role, navigate to Goal object permissions and enable both ‘Edit Goal’ AND ‘Bulk Operations on Goals’. The bulk operations flag is critical - single updates bypass this check, which is why individual API calls worked while batch failed.
-
Proxy User Configuration: Your API user needs ‘Access to Proxy as Another User’ permission under Admin Tools. Additionally, in Proxy Management, ensure the proxy user mapping includes ‘Manage Integration Tools’ permission. Batch endpoints validate proxy permissions differently than single-record endpoints.
-
Goal Plan Template Access: Verify your proxy user has explicit access to all goal plan templates involved in the bulk update. This is often overlooked but causes 403 errors when batch operations span multiple templates.
API Payload Structure for Batch Operations:
The correct OData $batch format for SF H1 2023:
POST /odata/v2/$batch
Content-Type: multipart/mixed;boundary=batch_123
--batch_123
Content-Type: multipart/mixed;boundary=changeset_456
--changeset_456
Content-Type: application/http
PATCH Goal(12345L)
{"status": "2"}
--changeset_456--
--batch_123--
Important Constraints:
- H1 2023 limits batch operations to 100 items per request
- Each changeset can contain max 50 operations
- Batch timeout is 120 seconds - chunk large updates accordingly
After configuring all three permission layers and using proper batch format, your automation should handle 200+ goals by splitting into multiple batch requests of 100 items each.
I hit this exact issue last quarter. Your payload structure looks wrong for SF batch operations. The Performance Management API requires the OData $batch format with proper changesets, not a simple JSON array. Each operation needs to be wrapped in a changeset with proper headers. Also, batch operations have a limit of 100 items per request in H1 2023 - you’ll need to chunk your 200 goals into multiple batches.