Role-Based Access to Field Service Booking APIs
Important: This information only applies to Oracle Fusion Field Service environments. You can verify whether you've Oracle Fusion Field Service or Oracle Field Service, by signing in and checking on the About page. This feature relies on Fusion Identity and Access Management (IAM) and Permission Groups which are available in Fusion only.
Oracle Fusion Field Service now supports Permission Groups for selected booking-related API operations. These permission groups can be assigned to job or duty roles in the Fusion Setup Manager > Security Console, which are then granted to users. Unlike the broader role-based security model, permission groups allow administrators to grant access only to the specific API operations that an integration or user requires.
It is important to note that the feature applies only to certain booking-related operations, such as retrieving availability, matching resources, or creating and updating field service activities. External applications, including Visual Builder extensions, custom booking portals, and third-party booking tools that authenticate through OAuth 2.0 must have the appropriate permission groups assigned to the user roles to successfully invoke these APIs.
The following permission groups are currently supported:
REST API Permission Groups
| Sl.No. | Permission Group Name | Permission Group Description |
|---|---|---|
| 1 | read:Field Service Booking Dependency | Returns a list of fields and properties that required by showBookingGrid API function to determine parameters of activity that is going to be booked. Grants access to
|
| 2 | read:Field Service Booking Grid | Returns the booking grid for booking an activity based on the criteria in the request. Grants access to
|
| 3 | read:Field Service Matching Resource | Returns a list of resources which can complete the activity based on the criteria in the request. Grants access to
|
| 4 | create:Field Service Activity | Creates a Field Service activity. Grants access to
|
| 5 | update:Field Service Activity | Updates a Field Service activity. Grants access to
|
| 6 | read:Field Service Activity | Returns a Field Service activity. Grants access to
|
Permission Groups can be assigned to a job or duty role. And the job or duty role can be assigned to a user.
A typical scenario for using these permission groups is a third-party call center application that books service appointments on behalf of customers. The integration role for this system might combine read:Field Service Booking Grid and create:Field Service Activity, enabling agents to check availability and schedule activities while preventing them from modifying or deleting existing activities.
Another example is when a field manager uses a Visual Builder extension to create and update service activities directly inside Oracle Fusion. In this case, the manager’s role would include create:Field Service Activity and update:Field Service Activity, granting the ability to make changes to activities while restricting other API operations.
Through these scenarios, it becomes clear how the permission groups allow administrators to design roles that enforce least privilege access. Only the specific APIs needed for a given process are accessible, reducing risk and aligning with best practices for security and compliance.
Business Benefits
- Safer integrations because only the APIs that a role needs are exposed, reducing security risks.
- Flexible access control as administrators can assign just the right level of permissions for different users and integrations.
- Consistency across Fusion since Field Service now follows the same security approach as other Fusion applications, simplifying administration.
Steps to Enable
To configure access:
- Open the Security Console in Oracle Fusion.
- Locate the job role or duty role which needs access to Field Service API.
- Open the role details and switch to Permission Groups tab.
- Click Add and add one or several permission groups listed above.
- Save the role.
- Assign that role to the user(s) or integration accounts that require access.
- Test API calls with OAuth 2.0 authentication to confirm access is working as expected.