Installing and Configuring Service Bridge for Providers

[Phillip Godwin]

This is the second in a series of Service Bridge articles. The first was Migrating from the Legacy Service Bridge Applications, and was aimed at helping current Service Bridge customers upgrade to the most recent version of Service Bridge.  This article will take a step back for those who have not yet experienced Service Bridge and walk through the installation and configuration of the provider application – Service Bridge for Providers.

 

About Service Bridge

 

Overview

Let’s start with an overview of Service Bridge for those who are not familiar with the application.

Service Bridge helps consumers, providers, and partners connect their ServiceNow instances to securely build business workflows across the ServiceNow ecosystem.

With Service Bridge a provider can connect their ServiceNow instances to those of their customers and partners who also use ServiceNow, through a quick and easy registration process.   Once the connection is in place the provider can easily collaborate across the service ecosystem through bi-directional workflows, enabling service transparency and a seamless experience for their customers.  Service Bridge consumers can now enter service requests and receive provider support while working from their own ServiceNow instance, without having to swivel chair to the provider support portal or another system.

With Service Bridge a provider can…

• Grow revenues with faster onboarding.
  New and updated service entitlements are published to subscribed customers’ service catalogs, and related requests pass between instances. This avoids the delays and loss of visibility that come with disjointed service portals and the manual passing of information.
  
  
• Improve their customers’ experiences.
  Resolving issues no longer requires time-consuming and error-prone emails and phone calls, or swivel-chairing information between the provider and their customers’ instances.  The customer is provided with a seamless, digital experience and their service is improved.
  
  
• Decrease their cost-to-serve.
  The Provider employee’s productivity is increased, and automation can be maximized using the systematic, structured tasks that are passed across the Service Bridge connection.

Key Service Bridge capabilities

Capability	Description
Onboarding	Quickly onboard consumers and partners that use ServiceNow with a simple registration process and avoid slow, costly custom integrations.
Authorized Users	Manage and control access at the Remote Catalog item level to meet security and compliance requirements.
Remote Catalog	Update subscriber service catalogs in minutes as new items are introduced.
Remote Choice	Ensure up-to-date field options in subscriber remote catalogs by retrieving real-time data from the provider's ServiceNow instance.
Remote Task	Reduce swivel-chairing and increase automation with seamless multi-party and multi-instance workflows across the ServiceNow ecosystem.
Provider Tasks	Enable provider transparency and customer collaboration by syncing relevant tasks like cases, to consumers as Provider Tasks.
Transform Framework	Transform inbound and outbound remote task data for easy process transformation between ServiceNow instances.
Foundation  Data Sync	Allow Service Bridge providers to synchronize CMDB CIs and other foundation data (asset, user, group, location, company, department) to connected customers.​

Service  Bridge applications

There are two Service Bridge applications:

• Service Bridge for Providers
  Service Bridge for Providers is the application that the Technology Provider installs on their instance.  If the Provider is licensed for the Technology Provider Service Management (TPSM), Telecommunications Service Management (TSM), or Media and Entertainment Service Management (MESM) products then they are entitled to install and use Service Bridge for Providers.
  
  Service Bridge for Providers features:
  
  • Send incidents and cases to the consumer's ServiceNow instance using a provider task (no setup required)
  • Author and publish service catalogs from the provider instance to the consumer’s instance Service Portal.  Related requests are sent back over the Service Bridge connection for fulfilment in the provider instance.
  • Bi-directionally integrate provider tasks with their service consumers' tasks

• Service Bridge for Consumers
  Service Bridge for Consumers is the application that the Technology Provider’s customers (consumers) install on their instance.  This application does not require a license.  It is free to any ServiceNow customer.
  
  Service Bridge for Consumers features:
  
  • Incorporate Remote Catalog items that the Providers have entitled to them into the service consumer’s local catalog, with the requests generated from the catalog sent over the Service Bridge connection to the provider for fulfillment.
  • Bi-directionally integrate consumer tasks with their provider's tasks.
  • Receive proactive advisory tasks from providers for transparency and collaboration.

The focus of this article is the installation and configuration of Service Bridge for Providers.  The next article in the series will move on to the topics of installing and configuring Service Bridge for Consumers and connecting to a provider instance.

Installing Service Bridge for Providers

Service Bridge for Providers enables a technology provider to connect to their consumers and partners who use ServiceNow, and should be installed on the technology provider’s instance.

The first step in installing Service Bridge for Providers is to verify that you have a valid entitlement to the application.  See get entitlement for a ServiceNow product or application for help with this task.

The procedure for installing Service Bridge for Providers is as follows:

1. Navigate to All > System Applications > All Available Applications > All
2. Find the Service Bridge for Providers application (sn_sb_pro) by using the search bar and filter criteria.
3. Search for the application by its name or ID. If the application is not found, request it from the ServiceNow Store.
4. Visit the ServiceNow Store website to view all the available apps and for information about submitting requests to the store.
5. In the application installation dialog, review the application dependencies. If any prerequisite plugins or applications are not yet installed, they must be installed before Service Bridge for Providers is installed.
6. Select Load demo data if so desired.  Demo data contains the sample records that describe the application features for common use cases.
7. Click Install.

Depending on  your ServiceNow Platform version and Service Bridge application version, Service Bridge may require platform updates to function.   A global script include is necessary in order to receive those updates and use Service Bridge for Providers (see KB1225292).  If you are running the Xanadu Patch 4 or higher ServiceNow platform release and are on Service Bridge application version 2.0.55 or higher this step is not required.

Here are the steps to install the global script include:

1. If you running Service Bridge v1.x.x download sb_v1.x.x.xml to your computer; if running Service Bridge v2.2.x download sb_v2.2.x.xml to your computer; and if you are running other versions of Service Bridge v2.x.x download sb_v2.x.x.xml to your computer.
2. Log in to the instance as an admin.
3. Navigate to System Definition > Scripts - Background.
4. Run the following script to delete the old sb include:

var sbcUtil = new GlideRecord('sys_script_include');

if(sbcUtil.get('e1034c0cc3511110331b4b46dd40dd0a')) {

sbcUtil.sys_policy = '';

sbcUtil.update();

sbcUtil.deleteRecord();

}

5. Navigate to System Definition > Script Includes.
6. From any of the list header menus select Import XML.
   
   
   
   
7. Select the file you downloaded and click Upload.
   
   
8. Navigate to System Definition > Script Includes.
9. Verify that sb is in the list.

You now have the script include and can proceed with using Service Bridge for Providers.

Service Bridge for Providers configuration

After installing Service Bridge for Providers on the provider instance, follow the steps below to configure Service Bridge before onboarding consumers.

Set up a new provider record

The provider record establishes a unique identifier for the Service Bridge for Providers (sn_sb_pro) application.

Roles required for setting up a new provider record:  admin, sn_sb.admin

1. Navigate to All > Service Bridge Provider > Provider.
2. Enter a name for the provider.
   The provider name can contain only alphanumeric characters and dashes. Names that include spaces or special characters will result in an error.
   
   
3. Click Submit.

Assign Service Bridge roles for providers

Set up the users with the roles that will be required to configure and manage Service Bridge for Providers.  Here are the common Service Bridge personas and the roles that enable their completion of common Service Bridge tasks:

Persona	Skills	Tasks	Roles
Administrator	Is a certified ServiceNow system administrator	Completes the Service Bridge registration requests. Assists the consumer's system administrator as needed. Publishes remote catalogs to the consumer's instance. Publishes remote task definitions to the consumer's instance. Troubleshoots Service Bridge transport payloads.	admin sn_sb.admin sn_transport.admin
Developer	Is a certified ServiceNow administrator Is a certified ServiceNow application developer	Creates provider connection records. Creates and maintains remote task definitions and transforms. Creates and maintains Flow Designer flows to determine the request fulfillment processes. Creates and maintains remote record producers.	admin sn_sb.admin Note: If the user does not have the admin role, the catalog admin role is required to modify and publish Remote Record Producers.
Provider Fulfiller	Has agent skills	Resolves consumer questions and issues. Engages in network operations when needed.	itil sn_sb.requestor sn_customerservice_agent sn_incident_read​/write sn_problem_read​/write sn_change_read/write
Consumer Requestor	End user	Makes requests from the Remote Catalog	sn_sb.requestor

Create catalog personas

A catalog user persona enables the control of Remote Catalog item access at a persona/role level.  When a Remote Catalog item is defined, the provider can specify what persona(s) will be allowed to access that catalog item.  “Authorized Users” (see Update Authorized User Settings below) can be assigned one or multiple personas, which then allows them to access the catalog items for which access is restricted to the assigned persona(s).

The provider created catalog personas are passed over the Service Bridge connection to a consumer instance as an entitlement.

Roles required for creating a catalog persona:  admin, sn_sb.admin

Here are the steps to create a catalog persona:

1. Navigate to All > Service Bridge Provider > Administration > Catalog Personas.
2. Click New.
3. Enter a name and description for the catalog persona.
   
   
4. Click Submit.

Create remote choice definitions

Service Bridge remote choice definitions define remote choice fields that allow consumers to securely retrieve choice data in real-time from the provider’s instance.  The provider maintains full control over the data, and there is no need to replicate foundation data between the provider and customer instances.

An example use would be a remote catalog item on the consumer’s instance for requesting server maintenance which requires the user to enter the name of a provider supported server.  Rather than relying on error-prone free-form entry from the user, costly recurring manual data transfer, or yet another custom integration; Service Bridge remote choice allows the most up-to-date supported server data to be referenced in real-time to provide the user with a list of supported servers that they can choose from.

Roles required for creating a remote choice definition: 

•    Creating a remote choice definition requires the security_admin role
• Role required to creating remote choice fields: admin

Here are the steps for creating a remote choice definition:

1. Elevate your role to security_admin.
2. Navigate to All > Service Bridge Provider > Administration > Remote Choice Definitions.
3. Click New.
4. Fill in the fields on the form as required. 
   
   
   Here are the fields and related descriptions:
   
   

   Field	Description
   Table	The name of the table that your consumers will query when selecting a catalog item on their service portal.
   Name	The name will be auto assigned but can be changed by a user with the security_admin role
   GlideRecordSecure	When this option is selected, all queries for this table follow the access control list (ACL) restrictions. When this option isn’t selected: Queries for this table ignore all ACL restrictions. Reference qualifier conditions must be specified for each remote choice variable to limit data access.
   AccountSecure	When this option is selected, the query results for the specified table are limited to those where the table’s Company or Account field matches the querying account’s Company field. Note: This flag is available only on the tables with references to the company or account where the field is named account, u_account, company, or u_company.
   Filter	Filter conditions to further limit the data that is returned from a query
   Short description	Additional information about the remote choice definition

5. Click Save and then click Publish.

The next section will review how to use remote choice definitions as part of a remote record producer.

Create remote catalog items

Using the Service Bridge remote catalog capability, a provider can create remote record producers that when published over Service Bridge (and approved by the consumer) will appear in the consumer’s service portal catalog.  When a consumer end user requests provider services using one of the remote catalog items in their instance, a Provider Task is created and sent over the Service Bridge connection to the provider instance.  According to the flow that is specified when the catalog item is created, the provider task will trigger creation of a related case, incident, or change request to fulfill the consumer request.

As the task moves through the fulfillment flow in the provider’s instance, updates are visible in both the provider and consumer instances.

Role required to create a remote catalog item:  sn_sb.admin

 Make sure that the scope is set to Global before you begin.

Here are the steps for creating a remote catalog item:

1. Navigate to All > Service Bridge Provider > Administration > Remote Catalog Items.
2. Click New
3. Fill in the fields on the form as required.
   
   
   
   Here are the fields and related descriptions:
   
   

   Field	Description
   Name	Name of the remote record producer
   Table Name	Table name is Provider Request. This is a read only field.
   State	This is a read only field and shows the status of the record producer. The UI action supports the following states: Draft - The form has been saved with the required information. Published - The form is published. Publishing - The form is yet to receive more information. Retired - The status is set to retired and the remote record producer can no longer be used.
   Flow	Choose one of the default Service Bridge flows provided or create your own flow if required. Create Case from Provider task Create Incident from Provider task Create change from Provider task
   Application	This is a read only field and is set by default based on the application scope.
   Active	This is a read only field and is enabled based on the Publish, Retire, or Edit actions.
   Expand help for all questions	Choose this option if you would like the help text for all the fields on the form to be displayed at all times
   Persona	Choose the catalog personas  that you want to be able to access this record producer on the consumer instance. Remote record producers without a persona defined can be accessed by any consumer user with the Service Bridge Requestor role
   Short Description	Short description for the record producer.
   Description	Detailed description for the record producer.

4. Click the link next to the Icon field to attach an icon to the catalog item
5. Click the link next to the Picture field to attach a picture to the catalog item
6. Click Submit
   
   
7. Add variables to the remote record producer (at least one is required).  Click the Variables tab in the Related Lists and then click New
8. Fill in the fields on the form as required.
   
   
   
   Here are the fields and related descriptions:
   
   

   Field	Description
   Application	This is a read only field and is set by default based on the application scope.
   Map to field	Select this option to map the variable to a specific field on the table for the record producer
   Type	Supported variable types: Break Check Box Container End Container Split Container Start Date Date/Time Duration Email HTML IP Address Label Masked Multi line text Multiple Choice Numeric Scale Requested For Rich Text Label Select Box Single Line Text URL Wide Single-Line Text Yes/No Note: The Attachment variable type is not supported.
   Remote choice enabled	Remote choice is an option when the variable Type is Reference Select this option to use a remote choice definition to reference choice data from the provider instance in this remote record producer.
   Catalog item	Catalog item that uses the variable
   Order	Placement order of the variable on the catalog item page. Variables are organized from top to bottom, and from the least to the greatest order value.
   Application	This is a read only field and is set by default based on the application scope.
   Active	This is a read only field and is enabled based on the Publish, Retire, or Edit actions.
   Mandatory	Option for making this variable mandatory when completing the catalog item
   Question	(Click on the Question tab) Question that is asked of the user who is completing the catalog item to obtain the related information
   Name	Name to identify the question (if left empty the value is auto-populated based on the Question field)
   Tooltip	Text to display when users point to the variable. Enter a brief note to describe the purpose of the question.
   Example text	Question field hint that appears before a user enters a value. You can use a hint for the following variables: IP Address Email URL Single Line Text Wide Single Line Text Multi Line Text Date Date/Time
   Type Specifications	(Click on the Type Specifications tab) This tab contains values specific to the variable type.  For remote choice variables type specifications include: The Remote choice definition to use for presenting choice data for this variable. Remote choice display field specifies the primary data value that appears in the reference field Remote choice additional info field optionally specifies a secondary data value that appears in the reference field. Reference qualifier condition optionally specifies additional filters to limit the data that is returned.

9. Click Submit
   
   
10. Repeat steps 7 through 9 as required to create additional variables for the same catalog item
11. Add a consumer criteria to specify which customers are entitled to the remote record producer.  Entitlements ensure that your customers have access only to the record producers that are associated with the service that they purchased. 
    To specify a consumer criteria for this remote record producer click the Consumer criterias tab in the Related Lists and then click New
    
    Click on the magnifying glass beside the Remote consumer criteria field to open the list of existing customer conditions.  If a customer condition already exists the meets the requirement select that condition from the list, otherwise click New
    
    
    
    Here are the fields and related descriptions:
    
    

    Field	Description
    Name	Name of the consumer criteria
    Condition for	Customer type: Account – B2B customer Company – internal/vendor Consumer – B2C customer
    Condition on	Table on which the conditions will apply.  For example, Sold Product [sn_install_base_product] The selected table determines the available elements in Customer Field
    Condition	Filters that allow further control of the customer condition
    Customer field	Field in the Condition on table for which the condition is evaluated. Select a Customer field based on the value of the Condition for field.  For example, if Condition for is set as Account and the Condition on table is Sold Product [sn_install_base_product], then select Account as the Customer Field.  In this example if the consumer account is found in the Sold Products table the then customer condition is met.

12. Click Submit to save the new customer condition.  This condition should now display in the Remote consumer criteria field.
    
    
13. Click Submit to save the new consumer criteria for this remote record producer
    
    
14. Click Publish to publish the remote record producer and make it available in the provider and consumer instances
    
    

Create remote task definitions

Remote tasks enable the bi-directional linking of tasks between Service Bridge provider and consumer ServiceNow instances without the need for custom integrations.  With Remote Task incidents, cases, requests, and other task types can be opened in the consumer instance, assigned to a provider, and then worked in the provider instance with status, updates, and comments syncing between the two instances.

The provider must first create and publish the remote task definition(s) that their consumers can use for creating a remote task. The remote task definitions are entitled to specific consumers using consumer criteria.  The consumers can adjust the mappings and field data rules as they require and the activate the definition on their instance.  Consumers can apply a trigger on the definition to activate a remote task, or manually create a remote task for the provider based on an active definition.

Role required to create a remote task definition: admin

The steps for creating a remote task definition are as follows:

1. Navigate to All > Service Bridge Provider > Administration > Remote Task Definitions.
2. Click New.
3. Fill in the fields on the form as required
   
   
   Here are the fields and the related descriptions:
   
   

   Field	Description
   Name	Name of the remote task definition record
   Provider table	Any task table selected from the available list
   Consumer table	Any task table selected from the available list
   Send attachments	If selected, an attachment on the parent record will be sent to the remote task.
   Copy attachment to parent	If selected, an attachment to the remote task will be copied to the parent record
   Short description	Short description of the remote task definition
   Description	Detailed description of the remote task definition

4. Select Submit
5. Open the newly created remote task definition record
   
   
6. Click on the Inbound fields tab to enter the fields that you will receive from the consumer instance when this definition is used to create a remote task.  If the inbound fields are updated in a remote task, the updated information is shown in a work note in the parent record on the consumer instance.
7. Click New to create a new field
8. Fill in the fields on the form as required
   
   
   Here are the fields and related descriptions:
   
   

   Field	Description
   Field label	Label that appears on the remote task form
   Field name	Name that is used in the remote task flow and script
   Max length	Maximum length of the field
   Sync when	This selection allows you to specify when a target field on the remote task's parent record is directly updated. Options: Insert: Updates the target field on the remote task's parent record only when the remote task is initially inserted. Insert or Update: Updates the target field on the remote task's parent record every time the remote is updated. Never: The inbound field never updates a target field on the remote task's parent record directly. For example, you can use this field for state mapping where a flow is used to convert the incoming value before updating the target field.
   Source Mapping tab	This tab is not displayed if the Virtual checkbox has been selected.
   Source table	Read only.  The consumer table selected when the remote task definition was created
   Source field	Field from the source table that is being sent from the consumer.  Note that Source fields allow for dot-walking to data in related tables.
   Target Mapping tab	This tab is displayed if Sync when is set to Insert or Insert or Update.
   Target table	Read only.  The provider table selected when the remote task definition was created
   Target field	Field from the target table that is receiving the consumer field data
   Active	Enabled by default
   Virtual	Select this check box to enable virtual inbound field mapping.  A virtual field in this context is a field that is present in the target table but does not exist in the source table. To update the target field, create a virtual inbound transform as described in the Create Transforms section below and associate the transform to this remote task definition.  The virtual inbound transform will use a script to determine the target field value.

9. Click Submit
10. Repeat steps 6-9 above until all required inbound fields are entered
    
    
11. Click on the Outbound fields tab to enter the fields that you will send to the consumer instance when this definition is used to create a remote task.  The outbound fields enable the provider to send data to the consumer’s instance when the remote task is created or updated.
12. Click New to create a new field
13. Fill in the fields on the form as required
    
    
    
    Here are the fields and related descriptions:
    
    

    Field	Description
    Field label	Label that appears on the remote task form
    Field name	Name that is used in the remote task flow and script
    Max length	Maximum length of the field
    Sync when	This selection allows the provider to suggest to the consumer when a target field on the remote task’s parent record should be directly updated. The consumer may change this setting before activating the definition.  Options: Insert: Updates the target field on the remote task's parent record only when the remote task is initially inserted. Insert or Update: Updates the target field on the remote task's parent record every time the remote is updated. Never: The inbound field never updates a target field on the remote task's parent record directly. For example, you can use this field for state mapping where a flow is used to convert the incoming value before updating the target field.
    Source Mapping tab	This tab is not displayed if the Virtual checkbox has been selected.
    Source table	Read only.  The provider table selected when the remote task definition was created
    Source field	Field from the source table that is being sent to the consumer.  Note that Source fields allow for dot-walking to data in related tables.
    Target Mapping tab	This tab is displayed if Sync when is set to Insert or Insert or Update.
    Target table	Read only.  The consumer table selected when the remote task definition was created
    Target field	Field from the target table that is receiving the provider field data
    Active	Enabled by default
    Virtual	Select this check box to enable virtual outbound field mapping.  A virtual field in this context is a field that is present in the target table but does not exist in the source table. To update the target field, create a virtual outbound transform as described in Section 4.7 – Create transforms below and associate the transform to this remote task definition.  The virtual outbound transform will use a script to determine the target field value.

14. Click Submit
15. Repeat steps 11-14 above until all required inbound fields are entered
    
    
16. Click on the Consumer criteria tab and then click New
    
    Click on the magnifying glass beside the Consumer condition field to open the list of existing customer conditions.  If a customer condition already exists the meets the requirement select that condition from the list, otherwise click New
    
    Here are the fields and related descriptions:
    
    

    Field	Description
    Name	Name of the consumer criteria
    Condition for	Customer type: Account – B2B customer Company – internal/vendor Consumer – B2C customer
    Condition on	Table on which the conditions will apply.  For example, Sold Product [sn_install_base_product] The selected table determines the available elements in Customer Field
    Condition	Filters that allow further control of the customer condition
    Customer field	Field in the Condition on table for which the condition is evaluated. Select a Customer field based on the value of the Condition for field.  For example, if Condition for is set as Account and the Condition on table is Sold Product [sn_install_base_product], then select Account as the Customer Field.  In this example if the consumer account is found in the Sold Products table the then customer condition is met.

15. Click Submit to save the new customer condition.  This condition should now display in the Consumer condition field.
    
    
16. Click Submit to save the new consumer criteria for this remote task definition
    
    
17. Click Publish to publish the remote record task definition and make it available in the provider and consumer instances
    
    

   Some things to note:

• If you no longer need a remote task definition and want to deactivate it, click Retire. Existing remote tasks can still use the retired remote task definition, but you cannot create any new remote tasks.
• Click Delete to delete a retired remote task definition if it is no longer required.
• To edit a published remote task definition, click Edit. Modify the remote task definition as required and click Publish.

The remote task definition is now active on the provider instance and is synchronized with the related consumers’ instance.  The consumers will need to review the related entitlement and activate the remote task definition in their instance.

Create Transforms

In most cases providers and their consumers will have different business processes and will track and manage those processes in different ways.  The Service Bridge transform framework provides a method for providers and consumers to transform data as required by their own process as it is passed back and forth over Service Bridge.

While using Service Bridge providers and consumers exchange remote task data through tables, forms, and fields. The transform framework capability allows data fields that have different value choices on the provider and customer’s instances to be translated/transformed as data is passed.   Both the provider and the consumer can create transforms.

There are four types of transforms that are possible with the Service Bridge transform framework:

• Simple transforms are used when the field to be transformed has a known and stable choice list on each instance. A simple transform example:  Customer State = “In Progress” in the provider instance and it is equivalent to Customer State = “Open” in the consumer instance.  A simple transform in Service Bridge will translate “In Progress” from the provider instance to “Open” on the consumer instance and vice versa.
  
  
• Advanced script-based transforms are used then the transformation between the instances is more complex.  Here is an example of an advanced transform script that transforms the passing of CI data:

output.value=input.value;

output.label=input.label;

var ci=new GlideRecord('cmdb_ci');

if(direction=='inbound'){

   if(ci.get('correlation_id',input.value)){

      output.value=ci.sys_id+";

      output.label=ci.getDisplayValue();

      }

}

if (direction=='outbound'){

  if(ci.get(input.value)){

     if(ci.correlation_id){

        output.value=ci.correlation_id+";

        output.label=input.label;

       }

    }

}

• Inbound transforms:  In the case where a field does not exist to receive data from the other instance, a virtual inbound field is used, and a script is required to create the inbound field and transform the incoming data as required.  Inbound transforms are run after a remote task is synced to the target instance to transform the data that is received. 
  
  
• Outbound transforms:  In the case where a field does not exist to send data to the other instance, a virtual outbound field is used, and a script is required to create the outbound field and transform the outgoing data as required. Outbound transforms are run on creation or updating of a remote task on the source instance to transform the data that is being sent.
  
  

Role required to create a transform:  admin

The following steps describe the process for creating a transform for providers:

1. Navigate to All > Service Bridge Provider > Administration > Transforms.
2. Click New
   
   
3. Fill in the fields on the form as required.
   
   
   Here are the fields and related descriptions:
   
   

   Field	Description
   Number	Auto-generated number for the transform record.
   Company	Consumer name that this transform will apply to
   All companies	The All companies field eliminates the need to define a specific transformation for each customer account when they have similar requirements. When this field is selected, the definition is used to transform specific fields across all companies simultaneously. The global “All companies” transform is applied only to companies that match the configuration and that do not have a specific transform already defined.
   Type	Simple: Used when the field has a known and stable choice list on each instance. A related list of transform lines is created to match the inbound and outbound values. Advanced: Used for complex criteria that requires a script to determine the new value. Virtual Inbound: Used to transform a virtual inbound field. Requires a script to determine the new value. Virtual Outbound: Used to transform a virtual outbound field. Requires a script to determine the new value.
   Inbound	This option enables an inbound transformation for this transform
   Outbound	This option enables an outbound transformation for this transform
   Provider table	The provider's task table that contains the field to be transformed. For example, Case.
   Provider field	The provider's field that is to be transformed. For example, State.
   Consumer table	The provider's task table that contains the field to be transformed. For example, Incident.
   Consumer field	The provider's field that is to be transformed. For example, State.
   Inbound field	When Type field is set to Virtual Inbound, this field is available to reference the virtual field this transform should populate.
   Outbound field	When Type field is set to Virtual Outbound, this field is available to reference the virtual field this transform should populate.

6. Click Save
   
   
7. Once saved the details of the transform must be entered.  Here is what is required for each of the 4 types of transformations:
   
   
   1. Simple:  When the transform type is Simple, a related list will be displayed after the Save.
      
      
      Choose New in the transform lines related list and fill in the fields on the form
      
      Here are the fields and related descriptions:
      
      

      Field	Description
      Provider label	The label of the provider’s field to be transformed.  For example, Open.
      Provider value	The value of the provider’s field to be transformed.
      Customer label	The label of the consumer’s field to be transformed.  For example, Progress.
      Customer value	The value of the consumers field to be transformed.

      
      
      
   2. Advanced:  When the transform type is Advanced you will be prompted after the save to enter a script to define the outbound and inbound labels and values.  Here is an example:
      
      
      
   3. Virtual Inbound:  When the transform type is Virtual Inbound you will be prompted after the save to enter a script to determine the inbound label and value.  Here is an example:
      
      
      
   4. Virtual Outbound:  When the transform type is Virtual Outbound you will be prompted after the save to enter a script to determine the inbound label and value.  Here is an example:
      
      
      
8. Click Submit
   
   
9. On the transform form, click Activate
   
   
   
   

Update Authorized Users settings

A provider can configure the settings for Authorized Users who have been created on the consumer’s instance.  This is done per consumer after the consumer has been onboarded.

Role required to update authorized users settings: admin

The following steps describe the process for updating the Service Bridge authorized user settings:

1. Navigate to All > Service Bridge Provider > Consumers.
2. Click the Number of the consumer connection you wish to configure.
3. After the Consumer Connection record is open click the Settings tab in the related links
4. Click the row value under Auto activate remote record producer to open the settings page
5. In the settings page, click the Authorized Users tab.

• Max authorized users: This field is available only if the Restrict authorized users flag has been enabled. Specify the maximum number authorized users that can be defined on the consumer's instance.
• Restrict authorized users: Select the check box if you want to restrict the number of authorized users on the consumer's instance.
• Auto approve authorized users: If this check box is selected, authorized users created on the consumer instance are automatically approved.

6. Click Update.

 You can view the settings defined in the Remote Record Producers and Remote Task Definitions tabs but cannot modify them on the provider instance.

After completing Service Bridge for Providers installation and configuration you are ready to begin connecting to your customers! 

Stay tuned for the next article in the series on registering and onboarding a new consumer connection.