Determine SSO Classification (Yes / No / Not Supported / Not Known)

Use this AI Prompt in a Torii Workflow to classify whether a discovered application is SSO-enabled (based on Torii discovery sources) or whether the vendor supports SSO but it isn’t currently integrated.

This guide is designed to:

1. Generate a single, strict output value via an AI (GPT) Action
2. Store that value in a single-select custom Application Details field
3. Persist it onto the app record via a Custom Action calling Torii’s Update app endpoint

What this prompt determines

The prompt returns exactly one of these values:

• Yes
  The app appears in an SSO/IdP discovery source (in this example: Okta), implying SSO is enabled.

• No
  The vendor/app supports SSO (SAML/OIDC/etc.), but the app is not present in the SSO/IdP source list.
  (Meaning: SSO could be enabled, but it’s not integrated via the detected IdP source.)

• Not Supported
  The vendor/app clearly does not support SSO.

• Not Known
  There isn’t enough reliable information to determine support.

Inputs (Torii personalization tokens)

This prompt uses:

• Application name: [Trigger.App.Name]
• Vendor name: [Trigger.App.Vendor]
• Discovery sources list: [Trigger.App.Sources] (list of systems where Torii discovered the app)

Output field (Application Details)

Create a single-select custom Application Details field (example: SSO enabled state) with these exact options:

• Yes
• No
• Not Supported
• Not Known

When you create the field, Torii assigns an Internal Name (custom fields typically start with c_).
You’ll use that internal name in the Update app API request.

Reference (Application Details settings):
https://support.toriihq.com/hc/en-us/articles/32565395389723-Settings-Application-Details

Workflow setup

1. Trigger: New application discovered (or any workflow where the subject app is set).
2. Action: AI (GPT) Action
   • Paste the prompt below
   • Add Response mapping to store the model output into a workflow token (example: SSO)
3. Action: Custom Action (HTTP Request)
   • Call PUT /apps/{idApp} to update the app record
   • Set your custom field internal name to the AI output token

AI (GPT) Actions documentation:
https://support.toriihq.com/hc/en-us/articles/36726298957083-AI-GPT-Actions

Prompt (paste into AI (GPT) Action)

# Prompt: Determine SSO Classification

```text
You are assisting with application governance inside Torii.

Your task:
Determine the correct SSO classification value for the discovered application.

Input:
You will receive application data including:
- Application name
- Vendor name (if available)
- A list of "sources" (systems from which the application was discovered, e.g., Okta, Google Workspace, Slack, Browser Extension, etc.)

Decision Logic (in order):

1. If any source name contains the word "okta" (case-insensitive):
   Return: Yes

2. If Okta is NOT in the sources:
   Determine whether the vendor/application supports SSO.

   - If the vendor clearly supports SSO (e.g., supports SAML, OIDC, SSO integrations), return:
     No

   - If the vendor clearly does NOT support SSO, return:
     Not Supported

   - If it is not possible to confidently determine whether the vendor supports SSO, return:
     Not Known

Input:
Application: [Trigger.App.Name]
Vendor: [Trigger.App.Vendor]
Sources: [Trigger.App.Sources]

Output Requirements:
- Return ONLY one of the following exact values:
  Yes
  No
  Not Supported
  Not Known
- If you are uncertain, return Not Known.
- Do not include JSON.
- Do not include punctuation.
- Do not include explanations.
- Do not include markdown.
- Do not include extra whitespace.
- Output must be exactly one of the allowed values.
```

Response mapping (AI action)

In the AI (GPT) Action, add Response mapping so the output is usable downstream.

Example:

• Name: SSO
• Value: the model response (single line)

Use the output: Update the app record (Custom Action → Update app endpoint)

This is the end-to-end pattern: AI output → workflow token → update the app record → populate Application Details field.

Step 1 — Identify your custom field internal name

In Settings → Application Details, locate your field (e.g., SSO enabled state) and copy its Internal Name.

Example internal name: c_sso

Step 2 — Configure the Custom Action (HTTP Request)

• Method: PUT

• URL: https://api.toriihq.com/v1.0/apps/[Trigger.App.ID]

• Headers:

  • Content-Type: application/json
  • Accept: */*
  • Authorization: Bearer <YOUR_TORII_API_KEY> (recommended: store in Secrets Vault)

• Body (example):

{
  "c_sso": "[AI action.response.SSO]"
}

Replace:

• c_sso with your field internal name
• SSO with the Response mapping token name you used in the AI action

Update app endpoint reference:
https://developers.toriihq.com/reference/putappsidapp

Testing checklist

1. Sources include Okta → expect Yes
2. No Okta, vendor supports SSO → expect No
3. No Okta, vendor does not support SSO → expect Not Supported
4. No Okta, cannot confirm support → expect Not Known

Customization

• If your org uses additional IdPs, expand the “Yes” check in rule #1 to match those source names (case-insensitive).
• If you want the model to research vendor SSO support, enable Search the web (requires your own OpenAI key):
  https://support.toriihq.com/hc/en-us/articles/38227217845531-Managing-AI-Settings