Role Based Access to Collaboration and Rescheduling Related APIs

Fusion Field Service now introduces Permission Groups for Collaboration and Rescheduling–related APIs, providing enhanced control and flexibility in managing API access. These permission groups can be assigned to job or duty roles within the Security Console and subsequently granted to users.

By complementing the existing role-based security framework, permission groups enable administrators to grant highly targeted access-ensuring that integrations and users are authorized only for the specific API operations they require. This approach strengthens security while simplifying access management.

The APIs impacted by this enhancement are listed in the table below. External applications, including Visual Builder extensions, that authenticate using OAuth 2.0 must have the relevant permission groups assigned to the appropriate user roles to successfully invoke these APIs.

The following permission groups for Collaboration Related APIs were added:

Permission groups for Collaboration related APIs

	Permission Group Name	Permission Group Code	Permission Group Description
1	Read Field Service Address Book REST Resource	oraCxFieldService_read_AddressBook_OraResource	Returns the address book in Field Service Collaboration. Grants access to  GET /api/field-service/collaboration/v1/addressBook
2	Create Field Service Chat REST Resource	oraCxFieldService_create_Chat_OraResource	Creates a chat in Field Service Collaboration.  Grants access to POST /api/field-service/collaboration/v1/chats
3	Leave Field Service Chat REST Resource	oraCxFieldService_leave_Chat_OraResource	Allows leaving a chat in Field Service Collaboration.  Grants access to POST /api/field-service/collaboration/v1/chats/{chatId}/leave
4	Read Field Service Chat Message REST Resource	oraCxFieldService_read_ChatMessage_OraResource	Returns messages from the chat in Field Service Collaboration. Grants access to  GET /api/field-service/collaboration/v1/chats/{chatId}/messages
5	Create Field Service Chat Message REST Resource	oraCxFieldService_create_ChatMessage_OraResource	Creates a chat message in Field Service Collaboration.  Grants access to POST /api/field-service/collaboration/v1/chats/{chatId}/messages
6	Read Field Service Chat Participant REST Resource	oraCxFieldService_read_ChatParticipant_OraResource	Returns participants of the chat in Field Service Collaboration. Grants access to  GET /api/field-service/collaboration/v1/chats/{chatId}/participants
7	Create Field Service Chat Participant REST Resource	oraCxFieldService_create_ChatParticipant_OraResource	Allows inviting participants to the chat in Field Service Collaboration. Grants access to POST /api/field-service/collaboration/v1/chats/{chatId}/participants/invite

The following permission groups were added for Activity and Resource APIs that are used during rescheduling:

Permission groups for Activity and Resource APIs

	Permission Group Name	Permission Group Code	Permission Group Description
1	Move Field Service Activity REST Resource	oraCxFieldService_move_Activity_OraResource	Moves Field Service Activity. Grants access to POST /rest/ofscCore/v1/activities/{activityId}/custom-actions/move
2	Cancel Field Service Activity REST Resource	oraCxFieldService_cancel_Activity_OraResource	Cancels Field Service Activity.  Grants access to POST /rest/ofscCore/v1/activities/{activityId}/custom-actions/cancel
3	Read Field Service Resource REST Resource	oraCxFieldService_read_Resource_OraResource	Returns Field Service Resource. Grants access to GET /rest/ofscCore/v1/resources/{resourceId}

The following permission groups introduced in 25D were renamed:

Permission Groups Renamed

	Old Permission Group Name	New Permission Group Name	Permission Group Code	Permission Group Description
1	read:Field Service Booking Dependency	Read Field Service Booking Dependency REST Resource	oraCxFieldService_read_bookingDependency_oraResource	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 GET /rest/ofscCapacity/v1/bookingFieldsDependencies
2	read:Field Service Booking Grid	Read Field Service Booking Grid REST Resource	oraCxFieldService_read_bookingGrid_oraResource	Returns the booking grid for booking an activity based on the criteria in the request.  Grants access to POST /rest/ofscCapacity/v1/showBookingGrid
3	read:Field Service Matching Resource	Read Field Service Matching Resource REST Resource	oraCxFieldService_read_matchingResource_oraResource	Returns a list of resources which can complete the activity based on the criteria in the request. Grants access to POST /rest/ofscCore/v1/resources/custom-actions/findMatchingResources
4	create:Field Service Activity	Create Field Service Activity REST Resource	oraCxFieldService_create_activity_oraResource	Creates Field Service Activity. Grants access to POST /rest/ofscCore/v1/activities
5	update:Field Service Activity	Update Field Service Activity REST Resource	oraCxFieldService_update_activity_oraResource	Updates Field Service Activity.  Grants access to PATCH /rest/ofscCore/v1/activities/{activityId}
6	read:Field Service Activity	Read Field Service Activity REST Resource	oraCxFieldService_read_activity_oraResource	Returns Field Service Activity. Grants access to GET /rest/ofscCore/v1/activities/{activityId} and GET /rest/ofscCore/v1/activities

Permission Groups can be assigned to job or duty roles, which are then granted to users. This structure provides flexible and precise control over API access while aligning with the existing security framework.

For third-party applications integrating with these APIs and requiring user identity context, Permission Groups should be used in conjunction with an OAuth 2.0 Authorization Code configuration in Oracle Cloud Infrastructure Identity and Access Management (IAM).

Configure OAuth Using Authorization Code Grant Type

In the case of an Authorization Code configuration, the involved parties are: the user, the application, the authorization server, and the resource server. For the user to get authorized, the application must be registered with the authorization server (in this case Oracle Cloud Infrastructure Identity and Access Management (IAM)). Therefore, you'll need to create a confidential application that can be accessed by multiple users but can keep the OAuth credentials confidential and protected. Let's look at how to do this in the application.

Never change the name of the OAuth token issuer.

This procedure focuses only on the fields and data entry points essential for the configuration. You can ignore and skip any other fields on the UI that aren't mentioned here. Where relevant, instructions to skip the fields are included in the procedure.

Register your client and resource applications with the authorization server.

1. Sign in to the Oracle Cloud Infrastructure Identity and Access Management (IAM) as an Administrator.
2. From the list of identity domains, click Integrated applications and click Add application.
3. On the Add application dialog box, select Confidential Application and click Launch workflow.
4. On the Add Confidential Application page, enter a name for the application that you're adding.
5. Skip all other fields and click Next.
6. In the Configure OAuth section, select Configure this application as a client now to proceed with the client configuration settings. Because you're creating a client application, only this option is relevant.
7. In the Authorization section, select the Authorization code checkbox to specify the grant type. This is the only grant type required for this flow.
8. In the Redirect URL field, enter the URL of your custom application that requires access to the Fusion Applications REST resources.
9. Skip the next few fields and go to the Token issuance policy section.
10. In Authorized resources, select specific so that the user is granted access only to the specific resources.

The Redirect URL path might vary depending on the type of application. Refer to the documentation of your custom application for the exact information regarding the redirect URL used for OAuth configuration.

Add resources for your product.

1. Select the Add resources checkbox to include the resources that are accessible to the users.
2. In the Resources subsection, click Add scope.
3. On the Add scope dialog box, select Oracle Fusion Field Service, and click Add. The resources are added. You'll notice that the scope defined by your application administrator is available in the format: 

   <resource audience name><resource scope name>

   . Make sure that scope "/" is added.

A scope determines the level of access you have to the application's resources. The scope is defined by the resource application administrator. To find the scope, go to your domain and look for the Oracle provisioned resource application, such as Oracle Fusion Field Service. On the service details page, go to the section OAuth Configuration, and then Configure application APIs that need to be OAuth Protected, and then Scopes. You'll find the scope listed in the table.

For the Authorization Grant Type you need to select the default scope which has the code "/".

Please note that in the Postman or cURL below you will need to use concatenation of the audience and scope. For example: urn:opc:resource:fusion:<env_id>:field-service-common/

where <env_id> - is specific environment id of your environment.

Complete application creation and activate the application.

1. After adding the resources, click Next and go with the default settings for the Web tier policy section. You don't have to modify any settings on this page.
2. Click Finish. A confirmation dialog box appears displaying the auto-generated Client ID and the Client Secret values.
3. Click Close. You're taken to the application page that you just created.
4. Click Activate. A confirmation message appears asking for a confirmation to activate the application.
5. Click Activate application. The confidential application is activated and ready for use.

Make a note of the Client ID and Client Secret values because you'll need them for requesting the access token.

Request an access token. You can do so using a client application such as Postman or a cURL command. Let's look at both these options.

Requesting access token

Using Postman

Using cURL

In Postman, create a new request. On the Authorization tab, select OAuth 2.0 as the Authorization Type. In the Configure New Token section, enter the following client configuration: Token Name: Enter a generic name for the token. Grant Type: Set the grant type to Authorization Code. Callback URL: Enter the Redirect URL value that's entered in the identity domain. Select the Authorize using browser checkbox to authorize the token generation through the browser. If you select this option, you'll notice that after authentication, the browser displays the authorization code appended to the application URL. Auth URL: The IDCS URL appended with /oauth2/v1/authorize is used as the Auth URL. You can get the URLs from https://idcs-<idcs-id>.identity.oraclecloud.com/.well-known/idcs-configuration. Access Token URL: The IDCS URL appended with /oauth2/v1/token is used as the Access Token URL. You can get the URLs from https://idcs-<idcs-id>.identity.oraclecloud.com/.well-known/idcs-configuration. Client ID: Enter the Client ID value that was auto-generated after creating the confidential application. Client Secret: Enter the Client Secret value that was auto-generated after creating the confidential application. Scope: Mention the scope defined in the identity domain. For example, urn:opc:resource:fusion:<env_id>:field-service-common/ Client Authentication: Select Send as Basic Auth Header. Click Get New Access Token. Postman passes on the information to the identity domain to authenticate and returns the access token.

Open a browser and send a request to obtain the authorization code using this URL: https://<domainURL>/oauth2/v1/authorize?response_type=code&client_id=<clientid>&redirect_uri=<redirect url>&scope=urn%3Aopc%3Aresource%3Afusion%3A<env_id>%3Afield-service-common%2F The browser gets redirected to the <redirect URL> specified in the confidential application. In the URL path, you can find the authorization code as a parameter. Copy the authorization code for use later in step 3. Launch the command prompt. Enter the cURL command below, replacing the text in angle brackets ( < > ) with the appropriate values: curl -u <clientid:clientsecret> --basic -H "Content-Type: application/x-www-form-urlencoded;charset=UTF-8" --request POST https://<domainURL>/oauth2/v1/token -d "grant_type=authorization_code&code=<authorization code>&redirect_uri=<redirect url>" d. You can expect the response in a format as shown here: Status: 200 "access_token":"eyJ4NXQiOiI4Wk. . ." "token":"Bearer", "expires_in":3600

Access the resource using the access token.

In Postman, click Use Token to use the token (auto-fill the Token field) and access the resources from the resource server. Or, if you used the cURL command in the previous step, you could continue with the command prompt to send the REST request and get access to the resources. You'd need to structure your request as shown here:

curl -X GET -H "Content-Type:<as needed by your REST endpoint, such as, application/json>" -H "Authorization: Bearer <access_token>" "https://<REST API endpoint URL>"

Note that the Authorization header is set to Bearer token and you'd provide the access token retrieved earlier as its value.

Business Benefits

• Strengthens least-privilege security for OAuth-based integrations by exposing only the API operations explicitly required by a role.
• Precise and scalable access administration as administrators can assign the exact permission groups needed, without over-provisioning broad API access. 
• Aligned security governance across Oracle Fusion since Fusion Field Service now uses the same permission-group approach used across other Fusion applications, simplifying role design and ongoing maintenance.

Steps to enable and configure

The feature is automatically available after the 26B upgrade. To configure access:

1. Open the Security Console in Oracle Fusion.
2. Locate the job role or duty role which needs access to Field Service API.
3. Open the role details and switch to Permission Groups tab.
4. Click "Add" and add one or several permission groups listed above.
5. Save the role.
6. Assign that role to the user(s) or integration accounts that require access.
7. Test API calls with OAuth 2.0 authentication to confirm access is working as expected.

Tips and considerations

• Grant least-privilege access. Assign only the permission groups required for the specific Collaboration and rescheduling APIs being invoked, and avoid bundling broader access than needed.
• Fusion-only dependency. This capability is available only in Fusion Field Service because it relies on Fusion Identity and Access Management (IAM) and Fusion permission groups.
• Account for renamed permission groups from earlier releases. If upgrading from prior configurations, review renamed permission groups introduced earlier to prevent mismatches when validating access.

Key resources

NA

Access requirements

NA