How-To Initiative: Candidate Topics

Working document — not published. Last updated: 2026-04-28. (P2-3 complete. P4-D complete: 14 candidates identified, items 14–17, 19–22, 24, 26 done; 25 skipped. P4-B complete: 257 connectors audited, priority gap list produced. P4-C on hold pending SE/PS input; NetSuite guide confirmed. P4-A/E pending.)

This catalog tracks the how-to guide initiative for Integration Studio. Phase 1 is complete (30 guides total). Phase 2 and Phase 3 candidates are documented below.

Phase 1: Complete

All 17 items from the Phase 1 writing order have been completed: 15 new guides written and 2 sets of edits applied to existing files.

Edits to existing guides

New guides written

Navigation note

All 15 new Phase 1 guides are listed in index.md. The final three — write-data-to-google-sheets.md, trigger-an-operation-from-a-webhook.md, and set-up-bidirectional-sync.md — were added alongside the Phase 2 and Phase 3 guides.

Phase 2: New candidates — recipes and templates

Source: function usage analysis of the cloud-studio-recipes (812 recipes) and cloud-studio-templates (49 templates) repositories.

Top functions not yet covered by any existing guide: - SHA1, SHA256, MD5 (2,000+ combined uses) - ReadCache, WriteCache (600+ combined uses) - ConvertTimeZone, GetUTCFormattedDateTime, FormatDate (405+ combined uses) - WriteFile + ReadFile + SendEmailMessage summary pattern (all 49 templates) - Replace, URLEncode (572+ combined uses)

Detect and deduplicate records using hash functions

Priority: High

Pattern summary: A sync operation computes a hash of source record fields using SHA1, SHA256, or MD5, then compares the result against a stored value to detect whether the record has changed since the last run. Records with a matching hash are skipped; records with a changed hash are processed and the stored hash is updated.

A second section covers within-run deduplication using ReadCache and WriteCache: the first time a key is encountered it is written to cache, and duplicate records later in the same dataset are skipped when the key is found in cache.

Source files to decompress: - cloud-studio-recipes/recipes/Sync_Salesforce_Contacts_to_HubSpot_Contacts.json - cloud-studio-recipes/recipes/Sync_NetSuite_Customers_to_Salesforce_Accounts.json - Any recipe with both ReadCache/WriteCache and a hash comparison in the same script

Proposed file name: detect-and-deduplicate-records-using-hash-functions.md

Proposed H1: Detect and deduplicate records using hash functions in Jitterbit Studio

Handle timezones in datetime operations

Priority: Medium

Pattern summary: Normalizes incoming timestamps to UTC for storage using GetUTCFormattedDateTime, shifts timestamps to a user-local timezone using ConvertTimeZone, and formats the result for display using FormatDate. The three functions are commonly used together in cross-region integrations where timezone mismatches cause data sync errors.

Source files to decompress: - cloud-studio-templates/Salesforce-NetSuite Opportunity-to-Order/Cloud Studio Projects/ (any project) - cloud-studio-templates/Epicor Kinetic-Salesforce Quote-to-Cash/Cloud Studio Projects/ (any project)

Proposed file name: handle-timezones-in-datetime-operations.md

Proposed H1: Handle timezones in datetime operations in Jitterbit Studio

~~Generate a summary log after processing records~~ Done

File: generate-a-summary-log-after-processing-records.md (2026-04-10)

Priority: Medium

Pattern summary: After a batch processing operation, accumulates per-record result lines into a string variable during processing, then sends the completed summary as an email body using SendEmailMessage. Optionally writes the summary to a file using WriteFile before sending. This pattern appears in all 49 process templates as the standard post-run notification step.

Note: Scope the guide to WriteFile (Jitterbit Script function) and SendEmailMessage — no file connector required. This avoids private-agent-only dependencies and keeps the scope consistent with send-an-email-notification.md, which this guide extends.

Source files to decompress: - cloud-studio-templates/Salesforce-NetSuite Opportunity-to-Order/Cloud Studio Projects/ (any project) - cloud-studio-templates/Workday-NetSuite Employee Onboarding-Offboarding/Cloud Studio Projects/ (any project)

Proposed file name: generate-a-summary-log-after-processing-records.md

Proposed H1: Generate a summary log after processing records in Jitterbit Studio

~~Build dynamic query strings for REST API calls~~ Done

File: build-dynamic-query-strings.md (2026-04-10)

Priority: Low

Pattern summary: Constructs a REST API query string at runtime where filter parameters vary based on source data. Uses string concatenation with Replace to substitute placeholder values and URLEncode to encode parameter values that contain special characters. Explains why URLEncode is necessary — values with spaces, ampersands, or special characters silently break requests without encoding.

Note: Scope to script-level URL construction (not the HTTP v2 activity's Request Parameters UI, which is covered in call-a-rest-api-using-the-http-v2-connector.md). The distinguishing case is when parameter names or structure vary at runtime, not just the values.

Source files to decompress: - cloud-studio-recipes/recipes/Sync_BigCommerce_New-Orders_to_Slack_Notifications.json - Any Salesforce sync recipe with a constructed SOQL query URL

Proposed file name: build-dynamic-query-strings.md

Proposed H1: Build dynamic query strings for REST API calls in Jitterbit Studio

Phase 3: In progress

Phase 3: Candidates — AI agent projects

Source: analysis of 7 AI agent project files in C:\Users\lisa.brown\Downloads\ai-agent-projects. These projects use current, recommended Jitterbit patterns and should be treated as high-authority sources.

Projects analyzed: - Fine Tune LLM Using OpenAI.json (504 KB) - HR Agent.json (2.6 MB) - Jitterbit AI Pricing Agent.json (1.7 MB) - Jitterbit Contact Agent.json (9.4 MB) - Jitterbit Sentiment Analysis Agent.json (3.7 MB) - LeadFlow AI agent.json (12 MB) - Meeting Notes Agent.json (3.2 MB)

Store and retrieve session state using Cloud Datastore

Priority: High

Pattern summary: Uses the Cloud Datastore connector to persist data between operation runs. Covers connection setup, storage creation, and the four core activities: insert items, update items, query items, and delete items. Demonstrates the pattern used across all five agent projects that implement conversation history: check whether a user record exists (query), then branch to insert (new user) or update (returning user). A secondary use case shows storing OAuth tokens across sessions.

Present in 5 of 7 AI agent projects: Jitterbit Contact Agent.json, HR Agent.json, Jitterbit Sentiment Analysis Agent.json, Meeting Notes Agent.json, and Fine Tune LLM Using OpenAI.json.

Note: Cloud Datastore connector docs are confirmed at source/docs-base/en/integration-studio/design/connectors/cloud-datastore/ (insert-items, update-items, query-items, delete-items activities documented).

Source files: - C:\Users\lisa.brown\Downloads\ai-agent-projects\Jitterbit Contact Agent.json (conversation history insert/update/query — the Cloud Datastore - Cache Last Message Controller flow) - C:\Users\lisa.brown\Downloads\ai-agent-projects\Meeting Notes Agent.json (token storage across sessions as a secondary use case)

Proposed file name: store-session-state-using-cloud-datastore.md

Proposed H1: Store and retrieve session state using Cloud Datastore in Jitterbit Studio

Route LLM responses to Studio operations using function calling

Priority: High

Pattern summary: Implements LLM function calling so that a language model selects which Studio operation to run in response to a user request. Covers two approaches:

1. Built-in Tools Router (recommended): Studio's built-in Tools Router component (step type 404, confirmed GA) handles tool manifest registration and dispatch automatically. The HR Agent uses this approach.
2. Manual Case-based dispatch: A script builds the tool manifest using AddToDict, includes it in the LLM request, parses the model's tool_calls response to extract the function name and parameters, and uses a Case statement to call the corresponding operation. The Contact Agent uses this approach.

Both approaches should be covered or acknowledged, since both appear in production AI agent projects.

Present in 6 of 7 AI agent projects.

Source files: - C:\Users\lisa.brown\Downloads\ai-agent-projects\HR Agent.json (built-in Tools Router: AskHR Function Calling Controller and OpenAI prompt controller scripts) - C:\Users\lisa.brown\Downloads\ai-agent-projects\Jitterbit Contact Agent.json (manual set.tools script + Case-based dispatcher)

Proposed file name: route-llm-responses-using-function-calling.md

Proposed H1: Route LLM responses to Studio operations using function calling in Jitterbit Studio

Authenticate API endpoints with JWT

Priority: Low — investigate source files before writing

Pattern summary: Uses the JWT connector's generateToken, decodeToken, and validateToken activities to secure an API Manager endpoint. One operation generates a signed JWT as part of a session initiation flow; a gateway operation validates the token on each subsequent request.

Before writing: Read the LeadFlow AI agent.json and Jitterbit Contact Agent.json projects in depth to confirm the complete auth flow. The source scripts in LeadFlow are largely unnamed, and the JWT usage in the Contact Agent needs verification. Promote to a confirmed writing candidate only if the source material shows a clear, complete pattern.

Present in 2 of 7 AI agent projects: LeadFlow AI agent.json and Jitterbit Contact Agent.json.

Source files: - C:\Users\lisa.brown\Downloads\ai-agent-projects\LeadFlow AI agent.json - C:\Users\lisa.brown\Downloads\ai-agent-projects\Jitterbit Contact Agent.json

Proposed file name: authenticate-api-endpoints-with-jwt.md

Proposed H1: Authenticate API endpoints using JWT in Jitterbit Studio

Process documents with AI using Google Drive and Google Docs

Priority: Deferred — write after P3-1 through P3-4 are complete

Pattern summary: Reads a document from Google Drive, parses its structured content using the Google Docs connector, passes the content to an LLM with a structured JSON output prompt, and posts the parsed summary to Slack. Sourced from Meeting Notes Agent.json, which is the only project using this pattern.

Note on adapter type: Meeting Notes Agent.json uses an adapter with id=AI — this is an older identifier for the standard OpenAI connector. The guide can reference use-openai-in-a-studio-operation.md for the LLM step.

Present in 1 of 7 AI agent projects: Meeting Notes Agent.json.

Source files: - C:\Users\lisa.brown\Downloads\ai-agent-projects\Meeting Notes Agent.json

Proposed file name: process-documents-with-ai.md

Proposed H1: Process documents with AI in Jitterbit Studio

Guides to skip

The following patterns are already covered by existing guides. Do not create duplicates.

Proposed writing order

Phase 2 and Phase 3 guides, sequenced by priority and interdependency.

1. ~~Use Azure OpenAI in a Studio operation (P3) — Fastest Phase 3 guide; same structure as the existing OpenAI guide.~~ Done.
2. ~~Store and retrieve session state using Cloud Datastore (P3) — Prerequisite context for the function-calling guide.~~ Done.
3. ~~Detect and deduplicate records using hash functions (P2) — High-frequency pattern; self-contained.~~ Done.
4. ~~Route LLM responses to Studio operations using function calling (P3) — Centerpiece AI agent guide.~~ Done.
5. ~~Receive Slack events in a Studio operation (P3) — References manage-asynchronous-operations.md and send-a-slack-notification.md; references P3-3 for what follows.~~ Done.
6. ~~Handle timezones in datetime operations (P2) — Self-contained.~~ Done.
7. ~~Generate a summary log after processing records (P2) — References send-an-email-notification.md and configure-error-handling-in-operations.md.~~ Done.
8. ~~Authenticate API endpoints with JWT (P3) — Investigate source files first; promote or skip based on findings.~~ Done.
9. ~~Build dynamic query strings for REST API calls (P2) — Short guide; no dependencies.~~ Done.
10. ~~Process documents with AI (P3) — Deferred until items 1–5 are complete.~~ Done.
11. ~~Handle failed messages using a Dead Letter Queue — Sourced from PR #3329 (JBMQ Dead Letter Queue pattern page).~~ Done.
12. ~~Filter database query results using API request parameters — Sourced from customer feedback: user confusion over how/where to apply API Jitterbit variables (jitterbit.api.request.parameters.*). The guide covers reading URL parameters from an incoming API request and using them in a Database Query activity WHERE clause.~~ Done.
13. ~~Map source dates to Salesforce Date fields and log response errors — Sourced from two open product enhancement tickets. Design Studio auto-generates starter scripts for these two patterns; Studio does not. Covers GetUTCFormattedDate/GetUTCFormattedDateTime for Date/DateTime field formatting, and If/WriteToOperationLog/FindByPos/SourceInstanceCount/SumString for per-record response error logging.~~ Done.

Phase 4: Research tasks

Each item below is a discrete research session. The session output is a set of specific guide candidates to add to a new writing order, not finished guides. Run one session at a time, append the findings to this catalog, then prioritize and queue.

P4-A: Design Studio parity gap analysis

Goal: Identify patterns that Design Studio auto-generates or guides users through step-by-step that Studio does not have a how-to guide for.

Rationale: Item 13 (Salesforce Date field mapping and response error logging) surfaced because Design Studio generates starter scripts for those two patterns automatically. There are likely more. Studio users doing the equivalent tasks manually have no guidance.

How to run this session: 1. Scan the Design Studio connector docs for connector activity configuration pages that describe generated transformation scripts or auto-populated script fields. 2. Cross-check each pattern against the existing Studio how-to index. Any pattern that Design Studio scaffolds but Studio leaves to the user is a candidate. 3. Focus especially on transformation-heavy connectors: Salesforce, NetSuite, Workday, ServiceNow, Coupa.

Expected output: 3–8 specific guide candidates with source material identified.

P4-B: Connector coverage gap analysis — Complete

Goal: Identify high-traffic connectors that have activity reference docs but no Studio how-to guide covering a real integration pattern.

Status: Complete (2026-04-28). 257 connector directories audited; connectors with how-to coverage identified; priority gap list produced below.

Connectors already covered by existing Studio how-to guides: Salesforce, Database, HTTP v2, Slack, Microsoft Teams, Email, Box, OpenAI, Azure OpenAI, Cloud Datastore, JWT, HubSpot (one sync pattern), MCP Client, Google Docs, Google Drive, Google Sheets, Google Pub/Sub, Azure Service Bus, Jitterbit MQ, SOAP, API connector.

Connectors with NO integration pattern coverage, ranked by recipe prevalence:

Note on Snowflake/MongoDB: Zero recipe filename matches. Not in scope for P4-C.

Recommended focus for P4-C: NetSuite, Microsoft Dynamics 365, ServiceNow, Workday (in that order).

P4-C: Connector-specific guide candidates — On hold

Status: On hold (2026-04-28). Recipe frequency is not a reliable proxy for user demand. Connector-specific guides beyond NetSuite should be prioritized based on direct input from Sales Engineering and Professional Services, who have real-world visibility into what guides would be most useful. Revisit this session after that consultation.

Exception: A NetSuite integration pattern guide is confirmed as a priority and should be written independently of the broader P4-C session. See the Phase 6 writing order.

When P4-C is reactivated: 1. Gather connector priorities from Sales Engineering and Professional Services. 2. For each confirmed connector, filter the recipe repo by connector name. 3. Decompress 3–5 representative JSONs per connector. 4. Read the transformation scripts for non-obvious patterns not covered by existing guides.

Expected output: 2–4 guide candidates per connector, with source files identified.

P4-D: AI agent project analysis — Complete

Goal: Identify new how-to patterns from AI agent project files not included in the Phase 3 analysis.

Status: Complete (2026-04-28). 9 projects analyzed; 14 guide candidates identified.

Agent files analyzed (all highest authority — treat as most current recommended patterns): - C:\Users\lisa.brown\Downloads\_Account Intelligence Agent.json - C:\Users\lisa.brown\Downloads\Meeting Notes Agent (3).json - C:\Users\lisa.brown\Downloads\ai-agent-projects\Fine Tune LLM Using OpenAI.json - C:\Users\lisa.brown\Downloads\ai-agent-projects\HR Agent.json - C:\Users\lisa.brown\Downloads\ai-agent-projects\Jitterbit AI Pricing Agent.json - C:\Users\lisa.brown\Downloads\ai-agent-projects\Jitterbit Contact Agent.json - C:\Users\lisa.brown\Downloads\ai-agent-projects\Jitterbit Sentiment Analysis Agent.json - C:\Users\lisa.brown\Downloads\ai-agent-projects\LeadFlow AI agent.json - C:\Users\lisa.brown\Downloads\ai-agent-projects\Meeting Notes Agent.json

Note: Scripts were stored as plain text in type-400 component scriptBody fields — no decompression required. The old Meeting Notes Agent and Meeting Notes Agent (3) are nearly identical; (3) adds the Copilot trigger endpoint.

Patterns exclusive to the new agent files (highest priority): - Copilot trigger endpoint integration (both new files) - Google Docs connector (both new files) - Google Drive connector (Meeting Notes Agent (3)) - Multi-round tool-calling loop with accumulated messages (Account Intelligence Agent) - Copilot-triggered per-user pipeline dispatch (Meeting Notes Agent (3))

Patterns in 3+ projects (high-confidence candidates): - OAuth 2.0 authorization code flow — 3 projects (Account Intelligence, Meeting Notes (3), Meeting Notes old) - Multi-turn conversation history in Cloud Datastore — 3 projects (Account Intelligence, HR Agent, Contact Agent) - LLM tool-calling loop — 3 projects (Account Intelligence, HR Agent, Contact Agent) - Slack typing indicator / delete message pattern — 3 projects (partial overlap with existing Slack guides; lower priority)

P4-D candidates

Implement an OAuth 2.0 authorization code flow with token storage

Priority: High

Pattern summary: A complete OAuth 2.0 authorization code flow for a third-party API (demonstrated with Gmail). Constructs an authorization URL with scopes and access_type=offline, presents it to the user via Slack, receives the authorization code at a callback API endpoint using $jitterbit.api.request.parameters.code, exchanges the code for access and refresh tokens via an HTTP v2 activity with an application/x-www-form-urlencoded body, and stores the refresh token in Cloud Datastore keyed by user identifier. A separate "check auth" step queries the datastore and performs token refresh using grant_type=refresh_token. The callback operation serves an HTML confirmation page using $jitterbit.api.response.body and $jitterbit.api.response.headers.Content_Type.

Key script excerpt:

// Construct authorization URL
$oauthUrl = "https://accounts.google.com/o/oauth2/v2/auth"
    + "?client_id=" + $client_id
    + "&redirect_uri=..."
    + "&response_type=code"
    + "&scope=https%3A%2F%2Fmail.google.com%2F..."
    + "&access_type=offline&prompt=consent";
$jitterbit.api.response = "{\"response_type\": \"ephemeral\", \"text\": \"" + $oauthUrl + "\"}";

// Callback: receive code and serve confirmation page
$authCode = $jitterbit.api.request.parameters.code;
$jitterbit.api.response.body = "<html><body><h2>Connected!</h2></body></html>";
$jitterbit.api.response.headers.Content_Type = "text/html";
$jitterbit.api.response.status_code = "200";

Source files: - _Account Intelligence Agent.json — primary source (Connect Gmail Script, OAuth Callback Script, Gmail Authentication Script) - Meeting Notes Agent (3).json — same pattern; adds Copilot trigger variant - ai-agent-projects/Meeting Notes Agent.json — same pattern (original version)

Proposed file name: implement-oauth-authorization-code-flow.md

Proposed H1: Implement an OAuth 2.0 authorization code flow with token storage in Jitterbit Studio

Notes: Depends on store-session-state-using-cloud-datastore.md (for token storage step) and trigger-an-operation-from-a-webhook.md (for callback endpoint setup). Gmail is used as the OAuth provider in source files but the pattern generalizes.

Read and parse Google Docs content

Priority: High

Pattern summary: Uses the Google Docs connector to fetch a document by ID, traverses the document JSON using GetJSONString with indexed paths (/body/content/[i]/paragraph/elements/[j]/textRun/content) to extract paragraph text, and reads person/personProperties/name and person/personProperties/email for @-mentioned contacts. Also demonstrates how to extract a Google Doc ID from a Gmail message body: the email body is base64url-decoded (swapping -/_ back to +// before decoding), then Index() and Mid() locate the document URL pattern (docs.google.com/document/d/) and extract the 44-character ID. The assembled text is passed to an LLM for processing.

Key script excerpt:

// Extract doc ID from Gmail body
$emailBodyBase64Clean = Replace($emailBodyBase64, "-", "+");
$emailBodyBase64Clean = Replace($emailBodyBase64Clean, "_", "/");
$emailBodyHTML = HexToString(BinaryToHex(Base64Decode($emailBodyBase64Clean)));
$startPos = Index($emailBodyHTML, "docs.google.com/document/d/")
    + Length("docs.google.com/document/d/");
$docId = Mid($emailBodyHTML, $startPos, 44);

// Traverse document structure for contact info
$personName = TrimChars(
    GetJSONString($FileData,
        "/body/content/[3]/paragraph/elements/[" + i + "]/person/personProperties/name"),
    "\"");

Source files: - _Account Intelligence Agent.json — primary source - Meeting Notes Agent (3).json — same pattern - ai-agent-projects/Meeting Notes Agent.json — same pattern (original version)

Proposed file name: read-and-parse-google-docs-content.md

Proposed H1: Read and parse Google Docs content in Jitterbit Studio

Notes: The Google Docs connector (adapterId: Google Docs) and Google Drive connector (adapterId: Google Drive) are both new connectors not covered by any existing guide. The Gmail HTTP v2 call to retrieve the email body uses base64url encoding with -/_ substitution before decoding — this is a non-obvious step that warrants explicit documentation. The doc path is set as a project variable passed to the connector activity.

Build a multi-turn LLM chat with conversation history

Priority: High

Overlap note: A full end-to-end guide covering this pattern at the agent level exists at /ai/agents/contextual/. The Studio how-to guide should be distinct: it focuses on the low-level script and transformation patterns (sumcsv(), GetInstance(), Unmap()) rather than the overall agent architecture. Reference the contextual agent guide as the higher-level companion.

Pattern summary: Implements a conversational memory pattern for LLM interactions where each user/assistant exchange is persisted in Cloud Datastore keyed by session identifier (typically Slack channel ID or user ID). Before each LLM call, the stored history is retrieved and assembled into a messages array. In the Account Intelligence Agent, history is accumulated as CSV rows using sumcsv() — one row per message with role and content columns — then converted to JSON via a transformation that maps columns to json/messages/item/role and json/messages/item/content. Optional tool_call_id and tool_name fields use Unmap() to be conditionally omitted when empty. In the Contact Agent, a Build History transformation uses GetInstance() to calculate the message index and alternates user/assistant roles based on even/odd position.

Key script excerpt:

// Build CSV history (Account Intelligence Agent)
message = Array();
message[0] = "system";
message[1] = $Generic_System_Prompt + "\nUserEmail:" + $slackUserEmail;
$messages = sumcsv(message);
$messages = $messages + "\n" + $historyMessages;
message[0] = "user";
message[1] = $chatGPTRequest;
$messages = $messages + sumcsv(message);

// CSV-to-JSON transformation target mappings
// json/messages/item/role      = role
// json/messages/item/content   = message
// json/messages/item/tool_call_id: if(length(trim(tool_call_id))==0, Unmap(), tool_call_id)
// json/messages/item/name:        if(length(trim(tool_name))==0,     Unmap(), tool_name)

Source files: - _Account Intelligence Agent.json — sumcsv() + CSV-to-JSON approach - ai-agent-projects/HR Agent.json — Cloud Datastore per-channel storage - ai-agent-projects/Jitterbit Contact Agent.json — GetInstance() + even/odd role assignment

Proposed file name: build-multi-turn-llm-chat-with-conversation-history.md

Proposed H1: Build a multi-turn LLM chat with conversation history in Jitterbit Studio

Notes: Distinct from the existing store-session-state-using-cloud-datastore.md (which covers Cloud Datastore basics) and route-llm-responses-using-function-calling.md (which covers tool dispatch). This guide focuses specifically on the message history array construction and persistence. The sumcsv() approach is the clearest implementation to use as the primary example; the GetInstance() variant can be noted as an alternative. Should reference the Cloud Datastore guide for storage setup.

Implement an LLM tool-calling loop

Priority: High

Pattern summary: Extends basic function calling (covered in route-llm-responses-using-function-calling.md) to handle multi-round tool use: after a tool operation executes, its result is appended to the messages array as a tool role message with the matching tool_call_id, and the LLM is called again with the extended messages. The loop continues until the model returns a response with no tool calls or a maximum iteration limit is reached. Tool definitions are registered as JSON with type: "function" schemas. The Account Intelligence Agent implements this in JavaScript: it checks call_llm_again, parses tools_resp, accumulates prior tool messages into tools_messages, and merges them with the base message array before each subsequent LLM call. The HR Agent uses Jitterbit script with gpt.registeredTools and call_llm_again flag variables.

Key script excerpt:

// Build Tools Resp Request (Account Intelligence Agent, JavaScript)
if ($call_llm_again === true && $function_name && $function_resp) {
    var req = JSON.parse($InAndOut);
    var tool_resp = JSON.parse($tools_resp);
    var prev_tool_messages = $tools_messages ? JSON.parse($tools_messages) : [];
    var messages_json = JSON.parse($non_tool_messages_json).messages;
    var tool_resp_message = tool_resp.choices[0].message;
    var tools_message_json = JSON.parse($tools_message_json).messages;
    prev_tool_messages.push(tool_resp_message);
    var new_tool_messages = prev_tool_messages.concat(tools_message_json);
    req["messages"] = messages_json.concat(new_tool_messages);
    $tools_messages = JSON.stringify(new_tool_messages);
    $InAndOut = JSON.stringify(req);
}

Source files: - _Account Intelligence Agent.json — JavaScript multi-round loop (primary source) - ai-agent-projects/HR Agent.json — Jitterbit script variant with gpt.registeredTools - ai-agent-projects/Jitterbit Contact Agent.json — Case-based dispatcher (single round; partial overlap)

Proposed file name: implement-an-llm-tool-calling-loop.md

Proposed H1: Implement an LLM tool-calling loop in Jitterbit Studio

Notes: Must be written as a sequel to route-llm-responses-using-function-calling.md, which covers single-round function calling. This guide covers the loop, accumulated tool messages, and tool_call_id tracking. The Account Intelligence Agent's JavaScript implementation is the cleanest example; the HR Agent's Jitterbit script variant should be noted for readers who prefer not to use JavaScript.

Connect to an MCP server using the MCP Client connector

Priority: High

Pattern summary: Uses the MCP Client connector (adapterId: MCP Client) to connect a Studio operation to a Model Context Protocol server, making the server's registered tools available for LLM tool calling. Covers connection setup (server URL, auth), retrieving the tool manifest from the MCP server, passing the manifest to an LLM as available tools, receiving a tool call response, forwarding the call to the MCP server for execution, and returning the result to the LLM for final response generation.

Source files: - source/docs-base/en/ai/agents/mcp-client.md — existing how-to guide at /ai/agents/mcp-client/

Proposed file name: connect-to-an-mcp-server.md

Proposed H1: Connect to an MCP server using the MCP Client connector in Jitterbit Studio

Notes: The full agent-level walkthrough already exists at /ai/agents/mcp-client/. The Studio how-to guide should focus on the connector-level pattern (connection setup, tool manifest retrieval, request/response cycle) as a reusable building block, distinct from the agent assembly guide. Read mcp-client.md in depth before writing to confirm the script-level details and avoid duplication.

Enrich contact data using ZoomInfo

Priority: Medium

Pattern summary: Uses the ZoomInfo API (via HTTP v2 connector) to enrich contact and company data. Authenticates by posting credentials to the /authenticate endpoint to obtain a JWT stored in zoom.jwt. A Case statement routes to different API endpoint paths (/search/contact, /search/company, /enrich/contact, /search/scoop) based on a core.zoom.resource variable, making the integration reusable as a generic ZoomInfo client. Retrieved data (name, job title, email, phone) is merged with Salesforce contact records using flat-to-JSON transformations.

Key script excerpt:

// ZoomInfo resource router
Case($core.zoom.resource == "contact",
        $core.zoom.object = "/search/contact";
, $core.zoom.resource == "authenticate",
        RunScript("<TAG>script:core. Load Zoom Info Authentication Request Body</TAG>");
        $core.zoom.object = "authenticate";
, $core.zoom.resource == "enrich_contact",
        $core.zoom.object = "/enrich/contact";
, $core.zoom.resource == "scoop",
        $core.zoom.object = "/search/scoop";
, $core.zoom.resource == "company",
        $core.zoom.object = "/search/company";
);

Source files: - ai-agent-projects/Jitterbit Contact Agent.json — primary source - ai-agent-projects/LeadFlow AI agent.json — same auth pattern; simpler usage

Proposed file name: enrich-contact-data-using-zoominfo.md

Proposed H1: Enrich contact data using ZoomInfo in Jitterbit Studio

Notes: New connector (ZoomInfo API via HTTP v2). The Case-based reusable API client pattern is the most instructive aspect and generalizes beyond ZoomInfo.

Create and update Jira issues

Priority: Medium

Pattern summary: Uses the Jira connector (adapterId: Jira) to create issues with standard and custom fields, and uses HTTP v2 PATCH requests to update specific custom fields after creation. The update payload builds a JSON array for multi-select custom fields (e.g., an application list) by splitting a comma-separated string and wrapping each value in {"value": "..."} format, trimming the trailing comma with RTrimChars. A search operation retrieves in-progress tickets using the Jira query activity.

Key script excerpt:

// Build Jira custom field update payload
If(length($it_application_list) > 0,
    applicationArray = Split($it_application_list, ",");
    valuearray = "";
    i = 0;
    While(length(applicationArray) > i,
        valuearray += "{\"value\":\"" + applicationArray[i] + "\"},";
        i++
    );
    $core.payload = "{\"fields\": {\"customfield_10185\": ["
        + RTrimChars(valuearray, ",") + "]}}";
);

Source files: - ai-agent-projects/HR Agent.json — primary source (Create Task in JIRA, Prepare Update Task in JIRA Payload)

Proposed file name: create-and-update-jira-issues.md

Proposed H1: Create and update Jira issues in Jitterbit Studio

Notes: New connector (Jira). The custom field array construction is the most instructive and commonly needed aspect. The guide would cover both the native Jira connector activity for creating issues and the HTTP v2 PATCH approach for updates.

Sync HubSpot form submissions to Salesforce

Priority: Medium

Pattern summary: Reads HubSpot form submission data using the HubSpot API (HTTP v2 connector), paginates by writing results to a temporary storage file and processing records one at a time using SelectNodes() on XML output, maps submission fields (email, first name, last name) to a common schema, checks Salesforce for duplicate leads by email using SfLookupAll(), and either creates or updates a Salesforce Lead record. After creation, a ZoomInfo enrichment call adds company and contact data.

Key script excerpt:

// Page through XML records from temp storage
data = ReadFile("<TAG>activity:tempstorage/.../Read Hubspot Data</TAG>");
nodes = SelectNodes(data, "//DocInfo");
counts = Length(nodes);
i = 0;
while(i < counts,
    node = nodes[i];
    xml = "<GetDocumentsResponse><Documents>" + String(node) + "</Documents></GetDocumentsResponse>";
    WriteFile("<TAG>activity:tempstorage/.../Write Hubspot Data By Page</TAG>", xml);
    FlushFile("<TAG>activity:tempstorage/.../Write Hubspot Data By Page</TAG>");
    RunOperation("<TAG>operation:Read Hubspot Data By Page</TAG>");
    i = i + 1;
);

Source files: - ai-agent-projects/LeadFlow AI agent.json — primary source

Proposed file name: sync-hubspot-form-submissions-to-salesforce.md

Proposed H1: Sync HubSpot form submissions to Salesforce in Jitterbit Studio

Notes: New connector (HubSpot). The SelectNodes() approach for processing XML records from temporary storage is a distinctive pattern. The JWT connector (adapterId: JWT) is used for authentication. This guide would reference perform-a-bulk-upsert-to-a-database.md structure for the upsert step, and enrich-contact-data-using-zoominfo.md for the enrichment step.

Process incremental records using a high-watermark

Priority: Medium

Pattern summary: Uses ReadCache / WriteCache to persist a high-watermark value (typically a LastModifiedDate) between operation runs, so that subsequent runs only retrieve and process newly modified records. On each run, the stored watermark is read from cache; if empty, a default is used. After processing, the maximum LastModifiedDate from the current batch is written back to cache as the new watermark. Demonstrated with Salesforce cases: the SOQL query uses LastModifiedDate > <watermark> as a filter, and SfLookupAll retrieves only changed records.

Key script excerpt:

// Read or initialize watermark
case_LM_cacheKey = project + "_SF_Case_LM";
caselastModifiedDate = ReadCache(case_LM_cacheKey, cacheStoreTime, "project");
if(length(trim(caselastModifiedDate)) == 0,
    caselastModifiedDate = $SF_Last_Modified_Date;
);

// SOQL filter using watermark
soql = "Select Id from case Where Case_Owner_or_Queue__c IN ("
    + $SF_Case_Queue_Filter + ") AND LastModifiedDate > "
    + caselastModifiedDate + " AND AccountId != null";
caseIDs2DArray = SfLookupAll("<TAG>endpoint:salesforce/...</TAG>", soql);

// Update watermark after processing
newCaselastModifiedDate = sflookup("...", "Select max(LastModifiedDate) from case");
WriteCache(case_LM_cacheKey, newCaselastModifiedDate, cacheStoreTime, "project");

Source files: - ai-agent-projects/Jitterbit Sentiment Analysis Agent.json — primary source

Proposed file name: process-incremental-records-using-a-high-watermark.md

Proposed H1: Process incremental records using a high-watermark in Jitterbit Studio

Notes: The ReadCache/WriteCache pair for run-to-run state persistence is a broadly applicable pattern, not limited to Salesforce or sentiment analysis. The guide should scope to the watermark technique itself and use Salesforce as the example source. References query-salesforce-records-using-soql.md for the SOQL query step.

Validate and enrich records before a CRM upsert

Priority: Medium

Pattern summary: Implements a multi-stage validation and enrichment pipeline before committing a write to a CRM. In the Contact Agent, an LLM acts as the routing controller: the system prompt instructs the model to require explicit user approval (phrases like "yes, create it" or "go ahead") before routing to the execute_create_contact stage, enforcing an approval gate by checking conversation history. In the LeadFlow Agent, the pattern is code-based: HubSpot form data is enriched via ZoomInfo before being conditionally created or updated in Salesforce using SfLookupAll() for existence checks.

Source files: - ai-agent-projects/Jitterbit Contact Agent.json — LLM-enforced approval gate - ai-agent-projects/LeadFlow AI agent.json — ZoomInfo enrichment before upsert

Proposed file name: validate-and-enrich-records-before-crm-upsert.md

Proposed H1: Validate and enrich records before a CRM upsert in Jitterbit Studio

Notes: The most interesting and distinctive aspect is the LLM-enforced approval gate (using conversation history to confirm user intent before a write). This is a safety pattern in agentic workflows not documented anywhere. Investigate before writing whether the approval gate logic is stable enough in source files to be recommended as a pattern.

Fine-tune an OpenAI model

Priority: Low

Overlap note: A full end-to-end guide for this pattern already exists at /ai/agents/fine-tuned-llm/, covering it in the context of building a complete AI agent. Any Studio-focused guide should be scoped to the low-level script and transformation patterns (multipart upload, polling loop, Responses API) rather than duplicating the agent-level walkthrough.

Pattern summary: Implements the complete OpenAI fine-tuning workflow: constructs a JSONL training dataset, uploads it via a multipart form POST using base64encode() in a transformation with json/request/root/multipart/fileData, submits a fine-tuning job request with method/type = "supervised", polls the job status with a While loop and sleep(200) until $status == "succeeded", captures the resulting fine_tuned_model ID, and calls the custom model via the OpenAI Responses API (v1/responses). The Responses API differs from Chat Completions: messages are passed as json/input/item/role and json/input/item/content; instructions are a separate field.

Key script excerpt:

// Poll for completion
iterations = 100;
iter = 0;
while($status != "succeeded" && iter < iterations,
    iter++;
    sleep(200);
    RunOperation("<TAG>operation:Get Status for Fine Tune Job</TAG>");
);
if($status != "succeeded",
    RaiseError("Fine tune job is not succeeded. Check OpenAI dashboard for status.")
);

Source files: - ai-agent-projects/Fine Tune LLM Using OpenAI.json — only source

Proposed file name: fine-tune-an-openai-model.md

Proposed H1: Fine-tune an OpenAI model in Jitterbit Studio

Notes: Single-project source; narrow audience. This was previously marked "Skip" (Phase 3 Guides to Skip). The multipart upload pattern and OpenAI Responses API are genuinely new content, but the overall guide has limited applicability. Promote to Medium only if the OpenAI Responses API angle is deemed valuable enough to cover on its own; otherwise keep at Low or skip.

Analyze files using OpenAI file inputs

Priority: Low

Pattern summary: Sends a file (CSV or PDF) to OpenAI for analysis using the File Inputs API. Downloads a file using HTTP v2 or a connector, decodes it from base64 using HexToString(BinaryToHex(Base64Decode($base64content))), and uploads it to the Chat Completions API via a multipart form POST. The transformation uses json/request/root/multipart/fileData/item/value = base64encode($InAndOut) to re-encode the decoded file content for the multipart body.

Source files: - ai-agent-projects/HR Agent.json — primary source (BambooHR CSV analysis, PDF CV analysis)

Proposed file name: analyze-files-using-openai-file-inputs.md

Proposed H1: Analyze files using OpenAI file inputs in Jitterbit Studio

Notes: The multipart upload pattern is shared with the fine-tuning guide. The base64 round-trip (decode then re-encode) is non-obvious and worth documenting. Consider combining this with the fine-tuning guide's multipart section, or cover the multipart upload pattern in call-a-rest-api-using-the-http-v2-connector.md as an extension.

Build an LLM-driven HR onboarding workflow

Priority: Low

Pattern summary: Orchestrates a complete employee onboarding flow across BambooHR, Jira, Confluence, Slack, and email. Retrieves employee records from a BambooHR custom report (HTTP v2), decodes and analyzes CSV configuration files using the OpenAI code interpreter, creates Jira IT tickets, sends personalized HTML email, and uses function calling to route between distinct onboarding phases (preboarding, offer signing, week-before, first-day). The Copilot PlatformBot trigger validates inbound events before dispatching.

Source files: - ai-agent-projects/HR Agent.json — only source

Proposed file name: build-an-hr-onboarding-workflow-with-bamboohr.md

Proposed H1: Build an HR onboarding workflow with BambooHR in Jitterbit Studio

Notes: Complex multi-system guide with low reuse outside HR use cases. BambooHR and Confluence are new connectors. May be better split: a focused "read BambooHR employee records" guide and a separate article on the Copilot PlatformBot integration. Only write if BambooHR connector coverage is specifically requested.

P4-E: Customer feedback and support ticket review

Goal: Identify documentation gaps based on recurrent "how do I..." questions from users.

Rationale: Item 12 (API request parameters guide) came directly from user confusion reports. Support tickets and GitHub issues are a reliable signal for what's missing, because they reflect real confusion rather than theoretical gaps.

How to run this session: 1. Review open GitHub issues on the docs repo tagged with "documentation gap" or similar labels. 2. Scan recent support tickets (if accessible) for patterns matching "how do I..." or "I can't find docs on..." for Studio functionality. 3. Cross-check each reported gap against the existing how-to index.

Status: Pending — requires access to support/issue queue. Confirm data source with user before running.

Expected output: 2–6 guide candidates sourced directly from user pain points.

P4-E candidate: Expose Harmony operations as LLM tools

Priority: High

Source: Sales Engineering feedback (2026-05-27). One SE reported success using a custom tools.json file to register Harmony workflows as LLM-callable tools via the Register Tools activity, but noted it required significant trial and error to figure out the schema format and invocation pattern. A second SE confirmed the need for best practices guidance on defining and calling tools using the AI connectors for agents that do not use MCP as a tool source.

Pattern summary: Defines a set of Harmony operations (operations that call REST APIs or use native connectors such as Salesforce, Slack, or ServiceNow) as LLM-callable tools by building a tool manifest that matches the LLM's expected function calling schema. The manifest is loaded into the request transformation before a Register Tools activity. When the LLM returns a tool_calls response, the function name is extracted and used to route execution to the corresponding Harmony operation. Covers:

1. Writing a tool schema (name, description, parameters) that maps each LLM function name to a Harmony operation.
2. Loading the schema into the Register Tools request transformation (static JSON file vs. dynamically built in a script).
3. Routing the tool_calls response to the correct Harmony operation.

Distinct from existing guides: - connect-to-an-mcp-server.md sources tool schemas from the MCP Client connector's List Tools activity. This guide covers the case where there is no MCP server and tool schemas are defined directly. - route-llm-responses-using-function-calling.md uses a script-built tool manifest without the Register Tools connector activity. This guide uses Register Tools.

Before writing: Obtain the SE's tools.json as a concrete source example. Engineering confirmation of the recommended schema format per connector (OpenAI, Amazon Bedrock, Google Gemini, Azure OpenAI) is required, as the expected JSON structure varies by LLM API. Do not write from inference.

Proposed file name: expose-harmony-operations-as-llm-tools.md

Proposed H1: Expose Harmony operations as LLM tools in Jitterbit Studio

Notes: References route-llm-responses-using-function-calling.md for the dispatch step. Should clarify the difference between MCP-sourced schemas (handled automatically by the List Tools → transformation → Register Tools pipeline) and custom schemas that the author must write and maintain.

Phase 5: Proposed writing order

P4-D candidates, sequenced by priority and interdependency. P4-A through P4-E research sessions (connector gaps, Design Studio parity, customer feedback) have not yet been run; items from those sessions will be appended here when complete.

1. ~~Implement an OAuth 2.0 authorization code flow with token storage (P4-D) — Highest-priority new pattern; appears in both new agent files. Depends on expose-an-operation-as-a-rest-api.md and store-session-state-using-cloud-datastore.md.~~ Done.
2. ~~Read and parse Google Docs content (P4-D) — New connector (Google Docs + Google Drive); present in both new agent files. Self-contained aside from an HTTP v2 endpoint.~~ Done.
3. ~~Build a multi-turn LLM chat with conversation history (P4-D) — 3-project pattern; builds on store-session-state-using-cloud-datastore.md.~~ Done.
4. ~~Implement an LLM tool-calling loop (P4-D) — 3-project pattern; sequel to route-llm-responses-using-function-calling.md.~~ Done.
5. ~~Trigger a Studio operation from Jitterbit Copilot (P4-D) — Retired. "Jitterbit Copilot" is not a real product; the label came from internal operation names in the template files. The pattern is covered by expose-an-operation-as-a-rest-api.md.~~
6. ~~Connect to an MCP server using the MCP Client connector (P4-D) — New connector; full agent-level guide already exists at /ai/agents/mcp-client/; Studio guide focuses on connector-level patterns.~~ Done.
7. ~~Process incremental records using a high-watermark (P4-D) — Self-contained; broadly applicable beyond the Salesforce/sentiment analysis source.~~ Done.
8. ~~Enrich contact data using ZoomInfo (P4-D) — New connector; 2-project pattern. References query-salesforce-records-using-soql.md for the Salesforce step.~~ Done.
9. ~~Validate and enrich records before a CRM upsert (P4-D) — Investigate approval gate pattern in source files before writing; may be adjusted in scope.~~ Done.
10. ~~Create and update Jira issues (P4-D) — Skipped. New connector with moderate complexity; not prioritized.~~
11. ~~Sync HubSpot form submissions to Salesforce (P4-D) — New connector; depends on items 21–22.~~ Done.
12. ~~Fine-tune an OpenAI model (P4-D) — Skipped. Full agent-level guide exists at /ai/agents/fine-tuned-llm/; narrow audience and single-project source.~~
13. ~~Analyze files using OpenAI file inputs (P4-D) — Covers two patterns: inline base64 data URI (PDF) and decoded text embedding (CSV with code interpreter). File: analyze-files-using-openai-file-inputs.md (2026-04-28).~~
14. ~~Build an LLM-driven HR onboarding workflow (P4-D) — Skipped. Complex multi-system guide with low reuse outside HR use cases; BambooHR connector coverage not requested.~~
15. Expose Harmony operations as LLM tools (P4-E) — Pending source material. Requires SE's tools.json and engineering confirmation of recommended schema format per connector before writing.

Format audit

Issues identified in the 15 pre-Phase-1 guides. Items resolved in Phase 1 are noted.