vania-janet/multiturn-rag-retrieval-data huggingface dataset:
[the Settings icon](https://cloud.ibm.com/docs-content/v1/content/50eddb8fd81f33092880335ff107a78ff5cd0f65/watson-knowledge-studio/images/settings.png) and then click Manage service details.
3. In the Manage users section of the Service Details page, click the Edit link next to a user.
4. Click the role of the user and choose the role you want to upgrade that user to. For more information about roles, see [User roles in Knowledge Studio](https://cloud.ibm.com/docs/watson-knowledge-studio?topic=watson-knowledge-studio-roles).

Important: You must create a workspace, associate a user with a document set, and assign an annotation task to a user before a user with the human annotator role can see any workspaces listed in the Knowledge Studio application. Set up the workspace as soon as possible after users register so they see your workspace when they first access the application. You might want to notify users after you set up the workspace to let them know that they can start annotating documents.
5. Optional: When you finish administering users in Knowledge Studio, exit the session by closing the web browser. The Knowledge Studio user interface does not provide an action for explicitly logging out.







 Deactivating user accounts 

Later, if you want to remove users, follow the previous steps to open the Service Details page. From the list of user IDs, find the user you want to remove and click Deactivate.

If users are assigned documents to annotate and you deactivate their accounts, their annotations are affected. If annotations made by deactivated users were not promoted to ground truth, those annotations are deleted.



 Related tasks 

[Creating and assigning annotation sets](https://cloud.ibm.com/docs/watson-knowledge-studio?topic=watson-knowledge-studio-documents-for-annotation)
To assign a different name to a referenced key, use the format NAME:NEW_NAME=KEY_A. For example, to add an environment variable named myKey for a single key key1 in a configmap that is named configmapName, use the value configmapName:myKey=key1.



This value is optional.

--env-sec, --env-from-secret
: Set environment variables from the key-value pairs that are stored in a secret by using one of the following ways:



* To add environment variables for all keys in a secret that is named secretName, use the value secretName. You can modify the environment variable names by specifying a prefix when referencing the secret. To specify a prefix, use the value PREFIX=SECRET_NAME. Each resulting environment variable has the format <PREFIX><NAME_OF_KEY_IN_SECRET>. For example, to set the prefix for all variable names of keys in secret secretName to CUSTOM_, use the value CUSTOM_=secretName. If the secret secretName contains KEY_A, the environment variable name is CUSTOM_KEY_A.
* To add environment variables for individual keys, use the format NAME:KEY_A,KEY_B. For example, to add an environment variable for a single key key1 in a secret that is named secretName, use the value secretName:key1. To assign a different name to a referenced key, use the format NAME:NEW_NAME=KEY_A. For example, to add an environment variable named myKey for a single key key1 in a secret that is named secretName, use the value secretName:myKey=key1.



This value is optional.

--ephemeral-storage, --es
: The amount of ephemeral storage to set for runs of the job. Use M for megabytes or G for gigabytes. This value is optional.

--force, -f
: Do not verify the existence of specified configmap and secret references. Configmap references are specified with the --env-from-configmap option.
"name": "accountId",
"value": "$ACCOUNT_ID"
},
{
"name": "serviceType",
"value": "platform-service"
}
]
}
]
}'

SubjectAttribute subjectAttribute = new SubjectAttribute.Builder()
.name("iam_id")
.value("EXAMPLE_USER_ID")
.build();

PolicySubject policySubjects = new PolicySubject.Builder()
.addAttributes(subjectAttribute)
.build();

PolicyRole policyRoles = new PolicyRole.Builder()
.roleId("crn:v1:bluemix:public:iam::::role:Administrator")
.build();

ResourceAttribute accountIdResourceAttribute = new ResourceAttribute.Builder()
.name("accountId")
.value("exampleAccountId")
.operator("stringEquals")
.build();

ResourceAttribute serviceTypeResourceAttribute = new ResourceAttribute.Builder()
.name("serviceType")
.value("platform-service")
.operator("stringEquals")
.build();

PolicyResource policyResources = new PolicyResource.Builder()
.addAttributes(accountIdResourceAttribute)
.addAttributes(serviceTypeResourceAttribute)
.build();

CreatePolicyOptions options = new CreatePolicyOptions.Builder()
.type("access")
.subjects(Arrays.asList(policySubjects))
.roles(Arrays.asList(policyRoles))
.resources(Arrays.asList(policyResources))
.build();
If the SAML assertion corresponds to one of the standard OIDC claims, it's automatically added to the identity token. The assertions that don't have a match, are ignored by default. If your SAML provider returns other assertions, it's possible to configure App ID to [inject the information into your tokens](https://cloud.ibm.com/docs/appid?topic=appid-customizing-tokenscustomizing-tokens). But, be sure not to add more information than necessary to your tokens as they're typically sent in HTTP headers and limited in size.

The standard OIDC claims that App ID attempts to map to your assertion:



* name
* email
* locale
* picture



If one or more of those values change on the identity provider's side, the new values are available after the user logs in again.



 What does App ID expect a SAML assertion to look like? 

The service expects a SAML assertion to look like the following example.

<samlp:Response xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" ID="s2202bbbbafa9d270d1c15990b738f4ab36139d463" InResponseTo="_e4a78780-35da-012e-8ea7-0050569200d8" Version="2.0" IssueInstant="2011-03-21T11:22:02Z" Destination="https://example.example.com/">
<saml:Issuer xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">idp_entityId</saml:Issuer>
<samlp:Status xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol">
The roles and scopes must be created exactly as they were in the previous instance with the same spellings.
3. Import the users to your new instance of the service.
curl -X POST "https://<region>.appid.cloud.ibm.com/management/v4/<tenantID>/users/import" -H "accept: application/json" -H "Authorization: Bearer <bearerToken>" -H "Content-Type: application/json" -d "{ "itemsPerPage": 2, "totalResults": 2, "requestOptions": {}, "users": { "id": "7ae804f3-0ed3-45f0-bc6b-1c6af868e6d6", "name": "{{site.data.keyword.appid_short_notm}} Google User profile", "email": "your@mail.com", "identities": { "provider": "google", "id": "105646725068605084546", "idpUserInfo": { "id": "{ID}", "email": "your@mail.com", "picture": "{profile.jpg}" } } ], "attributes": { "points": 150 } { "role": admin } }, { "id": "{userinfo}", "name": "{{site.data.keyword.appid_short_notm}} Facebook User profile", "email": "mail@mail.com", "identities": { "provider": "facebook", "id": "{id}", "picture": { "data": { "height": 50, "width": 50, "url": "https://{url}.com" } }, "first_name": "AppID", "last_name": "Development" } ], "attributes": { "points": 250 } { "role": admin } } ] ! ! ! ! ! !
ETCDCTL_API=3 etcdctl --cacert=c5f07736-d94c-11e8-a2e9-62ec2ed68f84 --endpoints=https://35dae549-2275-4d3e-baed-d86f36022336.974550db65eb4ec0983f023940bf637f.databases.appdomain.cloud:32460 --user=root:$PASSWORD user list





 Service Credential Users 

Users that you create through the Service Credentials panel are given the role rwall. They have access read and write access to all the keys in the database.

If you need users that are created from Service Credentials to have a different role, you can use the root user to change their role.





 Users who are created through the CLI and the API 

Users that are created in the CLI and API get the same role as Service Credential users, rwall. They have access read and write access to all the keys in the database. If you need them to have a different role that you have created, you can use the root user to change their role.

Users that are created directly from the API and CLI do not appear in Service Credentials, but you can add them if you choose.





 Users created in etcd 

You can bypass creating users in Service Credentials, the CLI, the API, and [create users directly in etcd](https://etcd.io/docs/v3.4.0/op-guide/authentication/working-with-users).

Users who are created directly in etcd do not appear in Service Credentials, but you can [add them there](https://cloud.ibm.com/docs/databases-for-etcd?topic=databases-for-etcd-connection-stringsadding-users-to-_service-credentials_)) if you choose.





 The compose user 

If you use etcdctl to list the users on your deployment, you might have noticed a user that is named compose. The compose user is the internal administrative account that manages replication, cluster operations, and other functions that ensure the stability of your deployment.
[Actions icon](https://cloud.ibm.com/docs-content/v1/content/d4595e5202a9a27767cf034e81b038cdf772e0d5/secure-enterprise/includes/account/includes/icons/action-menu-icon.svg) > Edit next to the access policy you want to update.
4. To assign new access policies, click Assign.



You can select your resources based on resource attributes and assign any combination of roles.





 Assigning access groups 



1. Click the name of the trusted profile that you want to update.
2. Click Access
3. To edit existing access group membership, click the Actions icon ![Actions icon](https://cloud.ibm.com/docs-content/v1/content/d4595e5202a9a27767cf034e81b038cdf772e0d5/secure-enterprise/includes/account/includes/icons/action-menu-icon.svg) > Edit next to the access group you want to update.
4. To add the trusted profile to a new access group, click Assign group.
5. Select the access groups to which you want to add the trusted profile and click Add. You can assign users to only the access groups that you have access to manage.
6. Click Assign.









 Updating session duration 



1. Click the name of the trusted profile that you want to update.
2. In the federated users section, click the Actions icon ![Actions icon](https://cloud.ibm.com/docs-content/v1/content/d4595e5202a9a27767cf034e81b038cdf772e0d5/secure-enterprise/includes/account/includes/icons/action-menu-icon.svg) for the identity provider (IdP) that you want to update.
3. Select Edit
4.
A customer ID that you specify is associated with the instance of the service whose credentials are used with the request; only credentials for that instance of the service can delete data associated with the ID.

Use the X-Watson-Metadata header with the following methods:



* With HTTP requests:



* POST /v1/synthesize
* GET /v1/synthesize



The customer ID is associated with data that is sent with the request.
* With WebSocket requests:



* /v1/synthesize



You specify the customer ID with the x-watson-metadata query parameter to associate the ID with data that is sent with the request. You must URL-encode the argument to the query parameter, for example, customer_id%3dmy_customer_ID.
* With requests to add custom words to custom models:



* POST /v1/customizations/{customization_id}
* POST /v1/customizations/{customization_id}/words
* PUT /v1/customizations/{customization_id}/words/{word}



The customer ID is associated with the custom words that are added or updated by the request.







 Deleting data 

To delete all data that is associated with a customer ID, use the DELETE /v1/user_data method. You pass the string customer_id={id} as a query parameter with the request. The following example deletes all data for the customer ID my_customer_ID:

IBM Cloud

curl -X DELETE -u "apikey:{apikey}" "{url}/v1/user_data?customer_id=my_customer_ID"

IBM Cloud Pak for Data

curl -X DELETE --header "Authorization: Bearer {token}" "{url}/v1/user_data?customer_id=my_customer_ID"

The /v1/user_data method deletes all data that is associated with the specified customer ID, regardless of the method by which the information was added. The method has no effect if no data is associated with the customer ID.
Can trusted profiles create user API keys? 

If you use a trusted profile, you can't create a user API key. You can still create and manage all other API keys. For example, service ID API keys.

To create a user API key, your IAM ID and the IAM ID of the user that's requesting the user API key must be the same. When you apply a trusted profile, you take on the IAM ID of that profile. To create a user API key for your identity, log out of IBM Cloud and log back in without applying a trusted profile.





 How can I check whether a user can apply a trusted profile? 

To check whether a user qualifies to apply a trusted profile by using the IBMid identity provider (IdP), the user and the administrator must complete specific steps.



1. The user must go to [IBM Cloud User Claims](https://iam.cloud.ibm.com/identity/claims).
2. From here, the claims are displayed.
3. The user must provide the claims to the administrator.
4. As the administrator, compare the claims of the user with the conditions set for the trusted profile. To view the conditions for a trusted profile, go to Manage > Access (IAM) > Trusted profiles in the IBM Cloud console.
5. Click the profile and view the Conditions column.
6. If the user's claims satisfy all of the conditions, the user can apply the profile.



If you are using a different IdP, check the user's claims in your corporate directory. Then, compare the claims of the user with the conditions set for the trusted profile. If the claims and the rules match, the user can apply the profile.





 How do I establish trust with the Kubernetes service in a trusted profile? 

In Kubernetes, a service account provides an identity for processes that run in a Pod, and namespaces provide a mechanism for isolating groups of resources within a single cluster. All Kubernetes clusters have a default namespace, and each namespace has a default account.
A customer calls the customer support phone number that is managed by your Session Initiation Protocol (SIP) trunk provider.
2. The SIP trunk service sends a SIP INVITE HTTP request to your assistant's phone integration to establish a connection.
3. The phone integration connects to the speech services that are required to support the interaction.
4. After the services are ready, the connection is established, and audio is sent over the Real-time Transport Protocol (RTP).

RTP is a network protocol for delivering audio and video over IP networks.
5. The greeting action of the assistant is processed. The response text is sent to the Text to Speech service to be converted to audio and the audio is sent to the caller.
6. When the customer says something, the audio is converted to text by the Speech to Text service and is sent to your assistant for evaluation.
7. The assistant processes the input and calculates the best response. The response text from the assistant is sent to the Text to Speech service to be converted to audio and the audio is sent back to the caller over the existing connection.
8. If the caller asks to speak to a person, the assistant can transfer the person to a call center. A SIP REFER request is sent to the SIP trunk provider so it can transfer the call to the call center SIP URI that is specified in the dialog node where the transfer action is configured.
9. When one of the participants of the call hangs up, a SIP BYE HTTP request is sent to the other participant.
The SIP trunk service sends a SIP INVITE HTTP request to your assistant's phone integration to establish a connection.
3. The phone integration connects to the speech services that are required to support the interaction.
4. After the services are ready, the connection is established, and audio is sent over the Real-time Transport Protocol (RTP).

RTP is a network protocol for delivering audio and video over IP networks.
5. The welcome node of the dialog is processed. The response text is sent to the Text to Speech service to be converted to audio and the audio is sent to the caller.
6. When the customer says something, the audio is converted to text by the Speech to Text service and is sent to your assistant's dialog skill for evaluation.
7. The dialog processes the input and calculates the best response. The response text from the dialog node is sent to the Text to Speech service to be converted to audio and the audio is sent back to the caller over the existing connection.
8. If the caller asks to speak to a person, the assistant can transfer the person to a call center. A SIP REFER request is sent to the SIP trunk provider so it can transfer the call to the call center SIP URI that is specified in the dialog node where the transfer action is configured.
9. When one of the participants of the call hangs up, a SIP BYE HTTP request is sent to the other participant.









 Phone integration limits 

Any speech service charges that are incurred by the phone integration are included as Voice add-on charges in your Watson Assistant service plan usage. The Voice add-on use is charged separately and in addition to your service plan charges.

Plan usage is measured based on the number of monthly active users, where a user is identified by the caller's unique phone number. An MD5 hash is applied to the phone number and the 128-bit hash value is used for billing purposes.

The number of concurrent calls that your assistant can participate in at one time depends on your plan type.



Plan details

 Plan Concurrent calls 

 Enterprise 1,000 
 Plus 100 
 Trial 5 







 Troubleshooting the phone integration 

Find solutions to problems that you might encounter while using the integration.
Making a call before processing a message 

Make a call to an external service or application every time a customer submits input. The external service can process the message before it is processed by your assistant.

A webhook is a mechanism that allows you to call out to an external program based on events in your program. Add a premessage webhook to your assistant if you want the webhook to be triggered before each incoming message is processed by your assistant.

The premessage webhook works with the v2 /message API only (stateless and stateful). For more information, see the [API reference](https://cloud.ibm.com/apidocs/assistant/assistant-data-v2message).

You can use a premessage webhook to do the following types of things:



* Translate the customer's input to the language that is used by your skill.
* Check for and remove any personally identifiable information, such as an email address or social security number that a customer might submit.



You can use this webhook in coordination with the postmessage webhook. For example, the postmessage webhook can do things like translate the response back into the customer's native language or add back information that was removed for privacy reasons, if necessary. For more information, see [Making a call after processing a message](https://cloud.ibm.com/docs/assistant-data?topic=assistant-data-webhook-post).

If you want to perform a one-time action when certain conditions are met during a conversation, use a dialog webhook instead. For more information about the dialog webhook, see [Making a programmatic call from dialog](https://cloud.ibm.com/docs/assistant-data?topic=assistant-data-dialog-webhooks).

For environments where private endpoints are in use, keep in mind that a webhook sends traffic over the internet. For more information, see [Private network endpoints](https://cloud.ibm.com/docs/assistant-data?topic=assistant-securitysecurity-private-endpoints).



 Defining the webhook
Making a call before processing a message 

Make a call to an external service or application every time a customer submits input. The external service can process the message before it is processed by your assistant.

A webhook is a mechanism that allows you to call out to an external program based on events in your program. Add a premessage webhook to your assistant if you want the webhook to be triggered before each incoming message is processed by your assistant.

The premessage webhook works with the v2 /message API only (stateless and stateful). For more information, see the [API reference](https://cloud.ibm.com/apidocs/assistant/assistant-v2message).

You can use a premessage webhook to do the following types of things:



* Translate the customer's input to the language that is used by your skill.
* Check for and remove any personally identifiable information, such as an email address or social security number that a customer might submit.



You can use this webhook in coordination with the postmessage webhook. For example, the postmessage webhook can do things like translate the response back into the customer's native language or add back information that was removed for privacy reasons, if necessary. For more information, see [Making a call after processing a message](https://cloud.ibm.com/docs/assistant?topic=assistant-webhook-post).

If you want to perform a one-time action when certain conditions are met during a conversation, use a dialog webhook instead. For more information about the dialog webhook, see [Making a programmatic call from dialog](https://cloud.ibm.com/docs/assistant?topic=assistant-dialog-webhooks).

For environments where private endpoints are in use, keep in mind that a webhook sends traffic over the internet.



 Defining the webhook 

You can define one webhook URL to use for preprocessing every incoming message.

The programmatic call to the external service must meet these requirements:



* The call must be a POST HTTP request.
The action is called automatically, replacing a jump to another dialog node's response.
* You want to see how actions works.

In this scenario, you can pick an intent for the action to handle. If you plan for the action to be called from the dialog only, you can spend your time defining the user examples for the intent that triggers the dialog node. When you define the action, you can add one customer example only, reducing the time you need to spend building the action.







 Adding a call to an action 

Before you start, open the Actions page and check the following:



* The name of the action you want to call.
* If the action you want to call uses a session variable, and you want to pass a value to the action by setting the session variable value, make a note of the session variable's ID.

In the Variables section, click to open the session variable. You can see the syntax that is used for the variable name in the ID field. Copy the variable ID to the clipboard.

You also need to understand the type of value to assign to the session variable. If you don't know, check how the session variable is used by the action.



To call an action from a dialog node:



1. From the dialog node, click Customize.
2. Set Call out to webhooks / actions to On.
3. Select Call an action.

When you add a call to an action, multiple conditional responses are enabled for the dialog node automatically.
4. Click Apply.
5. In the dialog node, choose the action you want to call.
6. Optional: If the action you want to call uses a session variable, you can set the value of the session variable when the action is started.

In the Parameters section, add a key and value pair to pass with the call to the action.

Add the variable ID (that you copied to the clipboard earlier) to the Key field, and in the Value field, specify the value that you want to set the variable to.

For example, let's say the action has a session variable named given name.