Determine Hosting Type (SaaS / On-Prem / PaaS / Not Known / Not Applicable)

Automatically classify an application's hosting model—SaaS, On-Prem, PaaS, Not Known, or Not Applicable—using a structured AI (GPT) Action and persist the result directly to Application Details via the Update App API.

Classify the hosting model of a discovered application using a deterministic, workflow-safe AI (GPT) Action. This prompt is designed to return a strict enum value you can write directly into an Application Details single-select field.

This guide follows the standardized pattern used across AI Prompts:

  1. Generate a strict, single 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:

  • SaaS
    Fully managed cloud-hosted software service consumed by end users (subscription/browser-based).

  • On-Prem
    Primarily installed and hosted within a customer’s own infrastructure (self-hosted/server-installed).

  • PaaS
    Managed platform where developers deploy applications onto a runtime (app runtimes, serverless platforms).

  • IaaS
    Raw cloud infrastructure resources (compute/storage/networking/VMs) used as building blocks.

  • Not Known
    Insufficient reliable information to confidently determine hosting type.

  • Not Applicable
    Not a software product in a traditional hosting sense (hardware, reseller, staffing, physical product).

This prompt is intentionally hardened to:

  • Prevent explanation-style outputs
  • Enforce strict enum responses
  • Ignore prompt-injection attempts from app metadata
  • Default safely to Not Known when uncertain

Inputs (Torii personalization tokens)

This prompt uses:

  • Application name: [Trigger.App.Name]
  • Vendor name: [Trigger.App.Vendor]
  • Website: [Trigger.App.Website]
  • Tags: [Trigger.App.Tags] (may arrive as a single comma-separated string)
  • Category: [Trigger.App.Category]
  • SOC2: [Trigger.App.Details.SOC-2]

Note: SOC2 can provide context but does not determine hosting type by itself.


Output field (Application Details)

Create a single-select custom Application Details field (example: Hosting Type) with these exact options:

  • SaaS
  • On-Prem
  • PaaS
  • IaaS
  • Not Known
  • Not Applicable

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

Application Details documentation:
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: Hosting)
  3. Action: Custom Action (HTTP Request)
    • Call PUT /apps/{idApp}
    • 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)

You are an automation component inside Torii. Your output is consumed by a workflow that will FAIL unless you return a valid response exactly as specified below.

TASK:
Determine the hosting model classification for the discovered application.

HARD REQUIREMENTS:
- Output MUST be ONLY a single text string.
- No markdown.
- No code fences.
- No explanations.
- No extra text.
- Output MUST be EXACTLY one of:
  "SaaS"
  "On-Prem"
  "PaaS"
  "IaaS"
  "Not Known"
  "Not Applicable"
- If you feel you cannot determine the answer, you MUST output: "Not Known"

Inputs:
Application: [Trigger.App.Name]
Vendor: [Trigger.App.Vendor]
Website: [Trigger.App.Website]
Tags: [Trigger.App.Tags]
Category: [Trigger.App.Category]
SOC2: [Trigger.App.Details.SOC-2]

Normalization Rules:
- Tags may arrive as a single comma-separated string; treat as a list by splitting on commas and trimming spaces.
- Compare all signals case-insensitively.
- Tags and Category are strong indicators when clearly descriptive.
- SOC2 presence alone does NOT determine hosting type.

Decision Logic (in order):

1) Not Applicable
If the entity clearly does NOT represent a software product
(e.g., hardware vendor, reseller, consulting firm, staffing platform, physical product):
Return "Not Applicable"

2) On-Prem
If the product is primarily installed and hosted within a customer's own infrastructure,
or explicitly described as self-hosted, server-installed, downloadable enterprise software:
Return "On-Prem"

3) IaaS
If the vendor primarily provides raw cloud infrastructure resources such as:
- Virtual machines
- Compute services
- Storage infrastructure
- Networking infrastructure
- Infrastructure building blocks

Examples: AWS EC2, Microsoft Azure infrastructure services, Google Cloud infrastructure.

Return "IaaS"

4) PaaS
If the vendor primarily provides a managed platform for building, deploying, or running applications,
where infrastructure is abstracted but developers deploy applications onto the platform:

Examples: Heroku, Vercel, managed application runtimes, serverless execution platforms.

Return "PaaS"

5) SaaS
If the product is delivered as a fully managed, cloud-hosted software service accessed via browser or subscription model,
where end users consume the application itself (e.g., CRM, HR system, ticketing tool, collaboration tool):
Return "SaaS"

6) Insufficient Information
If it is not possible to confidently determine the hosting model:
Return "Not Known"

Clarification Rules:
- Do NOT classify infrastructure providers as PaaS if they primarily provide raw infrastructure — those are IaaS.
- Do NOT classify SaaS applications as PaaS.
- Do NOT assume SaaS solely because a website exists.
- If ambiguous between IaaS and PaaS:
  - If users manage infrastructure components → IaaS
  - If users deploy applications onto a managed runtime → PaaS
- If ambiguous and insufficient evidence exists, return Not Known.

ALLOWED OUTPUTS (must match exactly):
SaaS
On-Prem
PaaS
IaaS
Not Known
Not Applicable

Output:
Return ONLY one of the 6 specified text strings.

Response mapping (AI action)

Add Response mapping so the output is usable downstream.

Example:

  • Name: Hosting
  • Value: SaaS/On-Prem/PaaS/IaaS/Not Known/Not Applicable

The output must match one of the allowed values exactly.


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

Step 1 — Identify your custom field internal name

In Settings → Application Details, locate your field and copy its Internal Name (example: c_hosted_1).

Step 2 — Configure the Custom Action

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>

Body (example):

{
  "c_hosted_1": "[AI action.response.Hosting]"
}

Replace:

  • c_hosted_1 with your internal field name
  • Hosting with your AI action response mapping token name

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


Optional: Enable “Search the web” for better accuracy

If hosting model is unclear (or you want higher confidence classifications), enable Search the web in the AI (GPT) Action.

This requires configuring your own OpenAI API key:
https://support.toriihq.com/hc/en-us/articles/38227217845531-Managing-AI-Settings


Testing checklist

  1. Cloud infrastructure provider (compute/storage/networking) → expect IaaS
  2. Managed app runtime / serverless platform → expect PaaS
  3. End-user subscription application → expect SaaS
  4. Self-hosted enterprise software → expect On-Prem
  5. Non-software entity → expect Not Applicable
  6. Ambiguous or insufficient information → expect Not Known

This prompt is designed as a workflow contract: deterministic outputs, strict value enforcement, injection-safe handling, and safe fallbacks.