Free cookie consent management tool by TermsFeed

AI Services

On This Page

Control generative AI models in your environment

Use the AI Services screen in the Admin Console to control which generative AI models are used in your Appian applications. As AI providers release models with improved capabilities, the AI Services screen allows you to adopt them in a secure and controlled way to benefit from the latest improvements in performance and accuracy.

Note:  Model Updates Required
AI models will be deprecated in certain AWS regions. See which models are impacted and what action is required.

Use the Appian tab to manage the generative AI models provided by Appian. When you select Appian as the cloud provider, the Appian tab includes Claude models, Amazon Nova 2 Lite, and GPT models (GPT 5.4 and GPT 5.5).

You can also configure a custom provider to route AI traffic through an internal AI gateway or proxy service. A custom provider lets you define a custom endpoint (Base URL) that points to your own infrastructure while still using a supported communication protocol, such as AWS Bedrock Converse, GCP Vertex, or Azure OpenAI.

Tip:  Amazon Nova 2 Lite is available for commercial Appian Cloud customers only and is not available for GovCloud environments. Administrators must configure an inference profile to enable Amazon Nova 2 Lite.

How AI model enablement works

You enable models when you select an inference profile in AI Services, making the model available to power various AI capabilities in your environment. For certain models, you must also select an inference profile. For Appian sites in a US region, the US inference profile is selected by default.

An inference profile is a setting that controls which geographic regions can process your AI data. Unlike single-region settings, inference profiles allow processing in multiple pre-defined regions. Inference profiles provide greater flexibility for data governance while ensuring access to the most powerful models.

Tip:  Use AI Guardrails to enforce content safety policies across all generative AI executions in your environment. Administrators configure guardrails in the Admin Console under AI Guardrails.

Model card status tags

Model cards display status tags to help you quickly identify the state of each model:

  • ENABLED: The model card displays this tag when an inference profile is selected for the model, indicating it is active.
  • DISABLED: The model card displays this tag when no inference profile is selected. The model card is grayed out to show it is inactive.

Scroll or drag to pan · ⌘+/⌘− to zoom · Esc to closeModel cards showing Enabled and Disabled status tags.

Considerations when enabling AI models

Enabling a model on the Appian tab changes which models are available for your AI capabilities. Before you enable a model, keep these considerations in mind:

  • System administrators can enable models and select inference profiles in the Admin Console. For sites in a US region, a US inference profile is enabled by default.
  • For FedRAMP sites, Appian AI models are automatically configured based on your service agreements and cannot be selected in the Admin Console.
  • If you select an inference profile that doesn't match your site's region, Appian automatically uses one of the regions defined in that profile to connect to the generative AI service. This does not cause an error.
  • Disabling a model by selecting None for its inference profile impacts any features that rely on that model. This is different from disabling an entire model provider, which prevents all routing to that provider's models at once.

Impact on AI capabilities when changing models

The following AI capabilities in AI Services automatically use the latest available models in the environment:

  • AI agents
  • CMS Data Type Recommendation
  • Composer
  • Data Fabric Chat
  • Process Insights
  • Sample Data Generation
  • Test Case Generation

Impact on generative AI skills

Generative AI skills behave differently than other AI capabilities when you change models.

  • New skills: By default, new AI skills are created with the latest available model in the environment. However, you can select any available model instead.
  • Existing skills: Your existing AI skills will not automatically update. To use the new model, you will see a banner in the prompt builder with instructions to perform the update. If a new model is not selected, existing skills will continue to use the previously available models.

AI skills automatically use the highest-priority supported model available in your region, including any model you explicitly select through an inference profile.

  • If that model is deprecated, the AI skill uses the next supported model.
  • If the selected model is unavailable during invocation and the provider is Appian, Appian executes a fallback to the next available model.
  • If no supported models are available, the AI skill returns an error.
  • If a model provider is disabled, Appian does not route requests to any models from that provider, even as a fallback.

Tip:  Although automatic fallback occurs, we recommend that you manually update and validate your model when deprecations occur.

Inference profiles: Control where your AI data is processed

Inference profiles define the regions through which data may move when using the model. Unlike single-region settings, inference profiles offer more flexibility by allowing processing in multiple pre-defined AWS regions.

inference profile configuration and data flow

Inference profiles are required for certain generative AI models. System administrators select the appropriate inference profile for your environment in the Appian Administration Console. When you choose a profile, the model card lists the supported regions so you can confirm where data will be processed before saving your chosen profile.

After you select an inference profile, review the supported regions on the model card for that profile. Confirm where data could be processed before saving your selection. For details about regional availability and inference profile concepts, see Regional Availability.

Scroll or drag to pan · ⌘+/⌘− to zoom · Esc to closeThe AI Services screen showing model cards with inference profile selection and supported regions.

Note:  Selecting an inference profile outside your site's primary region may introduce data latency.

Manage inference profiles

To enable or disable a model by selecting an inference profile:

  1. In the Appian Admin Console, go to AI Services.
  2. On the Appian tab, locate the model card for the model you want to configure.
  3. In the Inference Profile dropdown, select a profile to enable the model, or select None to disable it.
    • If you select None, review the warning in the confirmation message that disabling the model will impact application features that rely on it. Confirm your choice.
      Confirmation modal warning.
  4. After you select an inference profile, review the supported regions on the model card for that profile. Confirm where data could be processed.
  5. Click SAVE CHANGES to apply your changes.

Connect your own models

You can configure which AI provider powers Appian's generative AI features. By default, Appian uses its own infrastructure. However, you can bring your own provider to gain greater control over security, compliance, and cloud resource management. Appian supports three approaches:

  • AWS account: Connect your own AWS account to use Amazon Bedrock models directly. See Amazon Web Services.
  • Azure account: Connect your own Microsoft Azure OpenAI account to route LLM inference through your Azure environment. See Microsoft Azure.
  • Custom provider: Route AI requests through an internal AI gateway or proxy service using a custom endpoint. See Custom providers.

How model providers work

Configuring a model provider allows Appian features to use large language models (LLMs) from your own account or infrastructure. Model provider configuration applies only to LLM inference for generative AI features. Other AI capabilities like Advanced IDP and traditional ML Skills continue to use Appian's infrastructure.

Scroll or drag to pan · ⌘+/⌘− to zoom · Esc to closeArchitecture diagram showing the split between Appian-managed Textract and customer-managed Bedrock when using custom AWS credentials.

Default model provider behavior in AI Services

When an admin sets a provider as the default provider, Appian uses that provider for AI features where a developer has not explicitly chosen a specific model or provider. Default provider behavior means:

  • Features without model selection: AI capabilities like AI agents, Composer, and Data Fabric Chat automatically use the configured model provider.
  • Features with model selection: Developers can select from models offered by all enabled providers.

Tip:  If an admin does not set a default provider, Appian is the default provider.

Verify AI features after switching default providers

After switching default providers, test your AI capabilities to ensure they work as expected:

  1. Test an AI capability like Composer or data fabric chat to confirm it generates responses.
  2. If you have existing generative AI skills, test them in your applications to verify they execute successfully.
  3. Check the application server logs for any authentication or connection errors related to AI features.

If AI features fail after switching providers, verify that the new provider has the necessary models enabled and that your credentials (for AWS accounts) are configured correctly.

Revert to the Appian provider

You can switch between Appian's default provider and your own AWS account at any time.

To revert to Appian's provider:

  1. In the Appian Admin Console, go to AI Services.
  2. Select Appian from the model provider dropdown.
  3. From the context menu, select Set as Default Provider
    Context menu showing Set as Default Provider option.
  4. Click SAVE CHANGES.

Caution:  Switching providers may affect the availability of specific models or features if the new provider doesn't support the models in use by your applications. Review your applications before switching providers.

Amazon Web Services

You can configure your own AWS account as the model provider for Appian AI Services. Connecting your own AWS account gives you direct control over which Bedrock models are used and how your data is processed within your AWS infrastructure.

Security and connectivity

When you configure your own AWS account, Appian uses a secure architecture to manage credentials and validate connectivity to your Bedrock resources. The architecture includes credential protection and connectivity validation.

Scroll or drag to pan · ⌘+/⌘− to zoom · Esc to closeDiagram showing the flow of AWS credentials from the Admin Console to secure storage and the connection test to AWS Bedrock.

Credential protection for AWS accounts

Appian handles your AWS credentials with multiple layers of security to ensure they are never exposed:

  • Secure transmission: All credentials are transmitted over HTTPS.
  • Masked storage: The Access Key and Secret Access Key are masked after saving and are never displayed again in the Admin Console.
  • No logging: Sensitive credentials are never written to server logs.

Connectivity validation for AWS accounts

Before saving your configuration, the TEST CONNECTION feature performs a real-time validation against your AWS account. The connectivity test confirms:

  • Authentication: Your Access ID and Secret Access Key are valid for the selected region.
  • Permissions: Your IAM user has the required bedrock:InvokeModel permissions.

AWS IAM permissions prerequisite

Before configuring your AWS account, you must create an IAM (Identity and Access Management) user with the required permissions. Ensure your AWS administrator sets up this user before you configure your AWS account in Appian.

Your IAM policy must include at least the following permissions:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Action": [
                "bedrock:InvokeModelWithResponseStream",
                "bedrock:InvokeModel",
                "bedrock:GetFoundationModel"
            ],
            "Effect": "Allow",
            "Resource": [
                "arn:aws:bedrock:*::foundation-model/*",
                "arn:aws:bedrock:*:{YOUR_ACCOUNT_ID}:inference-profile/*"
            ],
            "Sid": "BedrockPermissions"
        },
        {
            "Action": [
                "bedrock:ListInferenceProfiles",
                "bedrock:ListFoundationModels"
            ],
            "Effect": "Allow",
            "Resource": "*",
            "Sid": "BedrockListPermissions"
        },
        {
            "Action": [
                "bedrock-mantle:CreateInference",
                "bedrock-mantle:CallWithBearerToken"
            ],
            "Effect": "Allow",
            "Resource": "*",
            "Sid": "BedrockMantlePermissions"
        }
    ]
}

Enable models on AWS Marketplace

Some Amazon Bedrock models are offered through AWS Marketplace and require a subscription before they can be used. The first time Appian calls one of these models on your AWS account, AWS attempts to enable the model automatically. This attempt fails if the IAM policy does not have the required permissions to subscribe. Use one of the following approaches to enable the model. If you use the IAM policy approach, it also grants the permissions needed for automatic enablement on first use.

Manual approach

An administrator on your AWS account can enable the model directly in the AWS Management Console. For details, see Simplified Amazon Bedrock Model Access on the AWS Security Blog.

Programmatic approach

To avoid manual steps, add the following statement to the Statement array in your IAM policy. This allows Bedrock to subscribe to Marketplace models automatically on first use:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
{
    "Sid": "AllowMarketplaceSubscription",
    "Effect": "Allow",
    "Action": [
        "aws-marketplace:ViewSubscriptions",
        "aws-marketplace:Subscribe"
    ],
    "Resource": "*",
    "Condition": {
        "StringEquals": {
            "aws:CalledViaLast": "bedrock.amazonaws.com"
        }
    }
}

Rate limits and capacity planning

When you use your own AWS account, you're responsible for managing the rate limits on your Bedrock resources. Ensure that the rate limits on your AWS account support the volume of AI requests you expect to process in Appian. If your rate limits are too low, AI features may fail or experience delays during high-usage periods.

To check and adjust your rate limits, see the AWS Bedrock documentation on quotas.

Connect your AWS account

Your AWS IAM user must have the required bedrock:InvokeModel permissions before you begin. See AWS IAM permissions prerequisite for the full policy.

To use your own AWS account as the model provider:

  1. In the Appian Admin Console, go to AI Services.
  2. Select Amazon Web Services from the model provider dropdown.
  3. Enter the following credentials:
    • Access ID: Your AWS access key identifier.
    • Secret Access Key: Your AWS secret access key. This value is masked after saving and doesn't display again.
  4. Select the AWS Region where your resources are located. This is the source region that Appian will use when calling Bedrock.
  5. Click TEST CONNECTION to validate your credentials and verify sufficient permissions.
    • Successful test: A green confirmation appears with the message "Test connection successful." This confirms your credentials are valid and have the required permissions.
    • Failed test: An error message appears indicating the issue. Common failures include:
      • Invalid credentials: Verify your Access ID and Secret Access Key are correct.
      • Insufficient permissions: Ensure your IAM policy includes the required Bedrock permissions.
      • Region mismatch: Confirm the selected region matches where your AWS Bedrock resources are configured.
  6. Click SAVE CHANGES to apply your configuration.

Note:  The AWS Secret Access Key is stored securely, transmitted over HTTPS, and never written to server logs.

Scroll or drag to pan · ⌘+/⌘− to zoom · Esc to closeimages/automation/aws-credentials.png

Deploy AI model provider configurations

When you deploy applications between environments that use your own model provider, you need to configure credentials for the target environment. AWS credentials are handled differently during export and import to protect sensitive data.

Export behavior for AWS credentials

For security reasons, AWS credentials are not included when you export Admin Console settings. The Access Key and Secret Access Key are never exported from the source environment.

Import behavior for AWS credentials

When importing an Admin Console settings file that includes AWS credentials, you must provide valid AWS credentials again in an import customization file. AWS credentials—including the default provider, keys, and inference profiles—are exported as a single unit. Because of this, you must include valid credentials in your import customization file even if you only modified the inference profiles.

The import customization file must contain:

  • AWS Access Key ID
  • AWS Secret Access Key
  • AWS Region

Caution:  If you do not provide these credentials in the import customization file, the import will fail.

If you want to maintain the existing AWS credentials in your target environment without modification, you can exclude them during the export process.

To prevent overwriting credentials:

  1. In the export dialog, deselect AWS Credentials.
  2. Complete the export.

When you exclude this option, the import process will not change any existing AWS configuration in the target environment.

For detailed instructions on setting up these files, see Managing Import Customization Files.

Microsoft Azure

Organizations that require generative AI traffic to remain within their Microsoft Azure environment can connect their own Azure OpenAI account to Appian. This gives administrators control over data residency, security boundaries, and cloud spend alignment with existing Microsoft Enterprise Agreements.

Azure OpenAI configuration applies only to LLM inference for generative AI features. AI capabilities that rely on non-LLM services — such as document extraction (Amazon Textract) and knowledge bases (OpenSearch) — continue to use Appian-provisioned infrastructure even when Azure OpenAI is configured.

Azure OpenAI prerequisites

Before configuring Azure OpenAI in Appian, retrieve the following credentials from the Azure Portal:

  • Endpoint: The base URL for your Azure OpenAI resource. Format: https://<your-resource-name>.openai.azure.com/
  • API key: An access key for your Azure OpenAI resource.

You must also create at least one model deployment in Azure OpenAI Studio and note the deployment name for each model you want to use in Appian.

Model deployment mapping

When you configure Azure OpenAI, you map your Azure deployment names to Appian-supported GPT models. This mapping tells Appian which of your Azure deployments corresponds to each supported model type, allowing Appian features to route requests to the correct deployment.

Connect your Azure OpenAI account

To configure Microsoft Azure OpenAI as a model provider:

  1. In the Appian Admin Console, go to AI Services.
  2. Select the Microsoft Azure tab.
  3. Enter your Endpoint.
  4. Enter your API Key.
  5. Click SAVE CHANGES.

After you save the provider configuration, you are directed to the Model list view where you can add models.

Note:  The API key is stored securely, transmitted over HTTPS, and never written to server logs. The key is masked after saving and does not display again in the Admin Console.

Add a model to Azure OpenAI

After configuring your Azure OpenAI account credentials, add models to map your Azure deployments to Appian features.

To add a model:

  1. In the Model list view, click Add Model.
  2. From the Select a model dropdown, select the GPT model that corresponds to your Azure deployment. The dropdown lists the GPT models supported by Appian.
  3. Enter a Display Name for the model. This is the label that appears in Appian when selecting the model.
  4. Enter your Deployment Name. This is the name of the deployment you created in Azure OpenAI Studio.
  5. Click TEST CONNECTION to validate that Appian can reach your Azure deployment using the configured credentials.
    • If the test succeeds, a confirmation message appears indicating the connection is valid.
    • If the test fails, verify that your endpoint URL, API key, and deployment name are correct and match those configured in Azure OpenAI Studio.
  6. Click SAVE CHANGES to add the model.

Tip:  You can add multiple models by repeating this process for each Azure deployment you want to use in Appian.

Set Azure OpenAI as the default provider

To set Azure OpenAI as the default provider so that AI capabilities use your Azure account automatically:

  1. In the Appian Admin Console, go to AI Services.
  2. Select the Microsoft Azure tab.
  3. From the context menu, select Set as Default Provider.
  4. Click SAVE CHANGES.

Caution:  If you set Azure OpenAI as the default provider without adding models, AI features will fail at runtime. Verify that you have added at least one model before switching the default provider.

Impact on generative AI skills

When Azure OpenAI is enabled, the models available in the Model Selection dropdown of an AI skill reflect the model equivalents configured by the administrator. The low-code configuration of AI skills remains the same regardless of the underlying provider.

Custom providers

A custom provider allows you to route Appian AI requests through an internal AI gateway or proxy service instead of connecting directly to a public cloud API. Custom providers are useful for organizations that require all AI traffic to pass through a centralized, internally managed platform for security, auditing, or regulatory compliance.

Custom endpoint (Base URL)

The Base URL is the root address of your internal AI gateway or proxy service. When you configure a custom provider, Appian sends AI requests to this address instead of the default public cloud endpoint.

The Base URL is combined with model-specific endpoint paths to form the full request URL. For example, if your Base URL is https://ai-gateway.example.com/api/v1 and a model's endpoint path is messages/sonnet4, Appian sends requests to https://ai-gateway.example.com/api/v1/messages/sonnet4.

Protocol and provider compatibility

While the endpoint is custom, the protocol—the API request and response structure—must still match a supported provider family. Appian supports the following protocols:

  • AWS Bedrock Converse
  • Azure OpenAI
  • GCP Vertex

Your internal gateway must accept and return data in the same format as the selected protocol. Appian does not transform requests into a proprietary format; it uses the standard API contract of the chosen provider family. Your proxy service is responsible for handling the request in that format and returning a compatible response.

Base URL and model endpoints

A custom provider separates configuration into two layers:

  • Provider level: The Base URL and authentication credentials apply to all models under the provider.
  • Model level: Each model defines its own endpoint path and protocol. The endpoint path is appended to the Base URL to form the full request URL.

The two-layer structure allows you to host multiple models behind a single gateway, each accessible at a different path, while sharing the same authentication and base address.

Add a custom provider

To add a custom provider:

  1. In the Admin Console, navigate to the AI Services page.
  2. From the model provider dropdown, select your custom provider.
  3. Enter a Display Name for the provider.
  4. Select the Authentication Type for connecting to your gateway:
    • API Key: Authenticates requests using an API key passed in a header.
    • Basic Auth: Authenticates requests using a username and password combination.
  5. Enter the authentication credentials required for the selected type.
  6. Enter the Base URL of your internal AI gateway or proxy service. This is the root address that Appian will use for all AI requests sent to this provider.
  7. Click SAVE CHANGES.

Note:  The provider is saved without any models. You must add at least one model before the provider can be used by AI features. See Add a model to a custom provider. The provider must also be saved and enabled before its models appear in the AI Skill object.

Add a model to a custom provider

After creating a custom provider, configure the specific models that Appian will leverage for generative AI features. Each model specifies the endpoint path, communication protocol, and model type. To see which models are supported by a given feature, use the AI Feature Model & Region Explorer.

To add a model:

  1. On the custom provider page, click Add Model.
  2. Select the Model Type that this model represents. The model type tells Appian which AI capabilities this model can power.
  3. Enter the Endpoint URL for the model. This path is appended to the provider's Base URL to form the full request URL.
  4. Select the Protocol that the model endpoint uses. The protocol must match a supported provider family, such as AWS Bedrock Converse, GCP Vertex, or Azure OpenAI.
  5. Click TEST CONNECTION to validate that the credential and model combination is reachable through the custom endpoint.
    • A successful test confirms that Appian can reach the model at the configured Base URL and endpoint path using the provider's credentials.
    • If the test fails, verify that the Base URL, endpoint path, credentials, and protocol are correct.
  6. After a successful test, click SAVE to add the model.

Caution:  You must successfully test the connection before saving a model. The TEST CONNECTION button validates that the full URL (Base URL + Endpoint URL) is reachable with the configured credentials.

Constraints and limitations

Keep the following constraints in mind when configuring a custom provider:

  • Supported models: See the Model Support and Deprecation page for supported models.
  • LLM inference only: Custom provider configurations apply only to LLM inference for generative AI features. Non-LLM capabilities, such as Advanced IDP and traditional ML Skills, continue to use Appian's infrastructure and are not affected by custom provider settings.
  • Protocol fidelity: Your proxy service must adhere to the exact JSON payload and header requirements of the selected protocol (for example, AWS Bedrock Converse, GCP Vertex, or Azure OpenAI). Appian does not transform requests into a proprietary format, so any deviation in the request or response structure may cause failures.
  • Latency: Internal gateways may introduce additional network hops, which can impact the response time of AI features like AI Copilot.
  • Rate limiting: Ensure your internal proxy is configured with throughput limits that support the expected volume of AI requests in your Appian environment. If limits are too low, AI features may fail or experience delays during high-usage periods.

Edit a custom provider

To update a custom provider's display name, authentication, or Base URL:

  1. On the AI Services page, select the custom provider.
  2. Click Edit.
  3. Update the desired fields.
  4. Click SAVE CHANGES.

Note:  Changing the Base URL or credentials may affect all models configured under this provider. After making changes, test each model's connection to confirm it is still reachable.

Set a custom provider as the default provider

You can set a custom provider as the default provider for your environment so that Appian routes all AI requests through your internal infrastructure. Before setting the default, ensure your provider meets the model coverage requirements.

Model coverage requirements for custom providers

Appian's AI features rely on different model types to function. If your custom provider is missing a model for a given type, any AI capability that depends on that model type will fail at runtime.

For example, if your custom provider does not include a model tagged for tool use, features like AI Copilot that rely on tool use will fail at runtime.

Caution:  To avoid disruptions, configure a model for every required type before setting the provider as the default.

The following table describes the model types that Appian AI features require. If your custom provider does not include a model for a given type, features that depend on it will fail at runtime.

Model type Description Used by
Fast Optimized for low-latency responses. Composer, Data Fabric Chat, CMS Data Type Recommendation, Sample Data Generation, Test Case Generation.
Reasoning Optimized for complex, multi-step tasks. AI agents, Process Insights.
Vision Supports image input for visual analysis. AI skills that process images.
Tool Use Supports function calling and tool execution. AI Copilot, AI agents.

Set a custom provider as the default

To set a custom provider as the default:

  1. On the AI Services page, select the custom provider.
  2. From the context menu, select Set as Default Provider.
  3. Click SAVE CHANGES.

Tip:  After setting a custom provider as the default, verify your AI features to confirm they work as expected.

Disable a model provider

You can disable an entire model provider at the environment level to prevent Appian from routing any AI requests to that provider's models. Disabling a model provider is different from disabling individual models — disabling a model provider blocks all models from that provider at once, regardless of individual inference profile settings.

Disabling a model provider is useful for organizations that need to certify their environment does not invoke models from a specific provider, such as meeting supply chain compliance requirements.

Note:  Disabling a model provider is an environment-level control. It applies to all AI capabilities in the environment, including Appian-internal services.

Scroll or drag to pan · ⌘+/⌘− to zoom · Esc to closeimages/automation/ai-services-settings.png

What happens when you disable a model provider

When you disable a model provider:

  • Appian does not route any AI requests to models from that provider.
  • The disabled provider's models are removed from the fallback chain. If a model is unavailable during invocation, Appian does not fall back to a disabled provider.
  • AI capabilities that depend on models from the disabled provider use an alternative provider if one is enabled. If no alternative is available, those capabilities return an error.
  • Appian records the change in the audit log with a timestamp, the actor who made the change, and the action taken.

Disable a model provider

To disable a model provider:

  1. In the Appian Admin Console, go to AI Services.
  2. Click SETTINGS.
  3. In the list of model providers, locate the provider you want to disable (such as Anthropic, Amazon, Meta, or OpenAI).
  4. Toggle the provider from Enabled to Disabled.
  5. Review the confirmation message that describes the impact on AI capabilities.
  6. Click SAVE CHANGES.

Considerations

Keep the following in mind when disabling a model provider:

  • Configure an alternative first. Before disabling a model provider, verify that an alternative provider is enabled and that your AI capabilities work with it. This prevents disruption to AI capabilities in your environment.
  • Disabling is different from setting a default. Setting a default provider controls routing preference. Disabling a model provider prevents any routing to it, including fallback.
  • Audit log entries. Appian logs model provider disable and enable actions in admin_console_audit.csv. Use these entries to verify compliance during audits. See Admin Console audit logs for details.

Feedback