Data 360 SQL AI functions: classify, score, and generate text

You can label support feedback inside a Data 360 query before building a separate enrichment pipeline. The choice is which operation you need: sentiment, a category from a fixed list, or newly generated text.

The current Data 360 SQL reference lists AI_SENTIMENT, AI_CLASSIFY, and AI_GENERATE_TEXT. The last function is explicitly beta. Choose the smallest operation that answers your question, test it on reviewed examples, and keep model output out of a customer-facing decision until you’ve measured its errors.

Classification and generation return different things

AI_SENTIMENT returns a text label: Positive, Negative, Neutral, Mixed, or Unknown. It accepts non-NULL input and supports up to 512 tokens. Salesforce documents a 30-second timeout and recommends starting with smaller row counts because initial large runs can encounter capacity errors.

For a support analyst, that makes it a candidate for questions such as whether recent delivery complaints sound more negative. It doesn’t determine whether the complaint is justified or whether the customer should receive compensation. Keep the source comment next to the label so a reviewer can investigate the result.

AI_CLASSIFY chooses a category from a text array you supply. The array must contain at least one unique value and stay constant across the query’s rows. Its reference also specifies non-NULL input, a 512-token limit, and a 30-second timeout.

The documented result is the selected category. Although the model chooses using confidence, don’t design a downstream confidence column around an assumed numeric return value. Confirm the output your query produces before defining the destination schema.

Write category descriptions a human can apply consistently. If reviewers disagree about whether a message belongs in “billing” or “refund,” fix that distinction before judging the model. Include a category for material outside your intended subject matter if your classification design needs one.

Use generation when a label cannot answer the question

AI_GENERATE_TEXT returns generated text for each input prompt. The beta reference names the Nemotron 3 Nano 30B model and requires Beta Generative AI Models in Einstein Setup. It also says generative AI features aren’t supported in Government Cloud Plus.

A prompt can be a literal, a column, or an expression combining fields. Because generation can vary between runs, a summary is a derived interpretation of the input. Preserve the source and the prompt version when that interpretation will be reviewed or reused.

For example, an internal analysis might ask for a one-sentence summary of a complaint. Avoid asking the same operation to infer refund eligibility from incomplete text. Put eligibility in a separate rule using authoritative order and policy data, then let the summary help a person understand the case.

The beta status belongs to this documented function. It shouldn’t be copied onto every AI function as a blanket label. Recheck the individual references when planning a production dependency because model availability and function behavior can change.

Bound the input before you scale the query

Start with a small, deliberately selected set of records. Include empty strings, multilingual comments, contradictory sentiment, category overlap, and long messages. Filter NULLs before invocation, and decide how to split long text without losing the context needed to classify it.

Compare the output with labels assigned by someone who understands the business. Count disagreements by category as well as overall. A frequent, easy category can hide poor performance on the rare category that matters most.

Store your evaluation inputs separately from the material used to refine categories or prompts. Otherwise, repeated tuning can produce a convincing score on familiar examples while doing little for new complaints.

For larger runs, restrict the source rows before model processing and measure timeout behavior. Avoid assuming an outer result limit bounds every intermediate operation. Read the query plan and validate the amount of work your query performs before scheduling it against a large table.

Decide where the result will live

A query result isn’t automatically a maintained enrichment field. If another process needs the label, design and verify a supported write path for your environment, whether an integration or a compatible transform. Check function support in that execution context before promising a scheduled pipeline.

Keep a source record identifier, processing timestamp, and category or prompt version with the derived result. Those fields let you explain why an old row differs after a later run and identify which records need reprocessing.

For customer-facing generation, compare the query approach with Prompt Builder, where template ownership and the calling action are part of the design. For analytics, the SQL functions may remove integration work, but you still need output checks and a refresh policy.

Measure the applicable consumption in your org’s Digital Wallet and check your contract before projecting cost. A Data 360 consumption plan should use observed query volume and applicable usage types, not an invented per-row rate. Publish the label to a downstream consumer only after that consumer’s owner agrees how uncertain or incorrect results will be handled.