بنقرة واحدة
appdb
Toolkit-first AppDB document CRUD, query operators, and collection wiring.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
القائمة
Toolkit-first AppDB document CRUD, query operators, and collection wiring.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
Step-by-step orchestrator for building Domo App Studio apps with native KPI cards via community-domo-cli. Sequences app creation, pages, theme, hero metrics, native charts, filter cards, layout assembly, and navigation. CLI-first — no raw API calls.
Domo KPI card CRUD via community-domo-cli — body schema, column mapping, beast modes, chart type index with on-demand reference files, and gotchas.
**Generating sample data for Domo** -- invoke when a user needs to create realistic sample datasets and upload them to a Domo instance. Primary signals: requests for sample data, demo data, test data, fake data for Domo; mentions of Salesforce, Google Analytics, QuickBooks, NetSuite, Google Ads, Facebook Ads, HubSpot, Marketo, or Health Portal sample data; questions about the datagen CLI or domo_data_generator. Covers: generating datasets, uploading to Domo, creating datasets in Domo, rolling dates, entity pools, connector icons, catalog management, and adding new dataset definitions. Skip for: real connector setup, production data pipelines, data transformations (Magic ETL), or Domo App Platform.
Create AppDB collections via CLI-first workflows where collection creation also provisions the required datastore, then returns collection identifiers for manifest wiring and document-write follow-up. Use when an agent must initialize new AppDB storage for a Domo app, not just list/get collections or create documents.
Create Domo Code Engine packages from CLI workflows with deterministic payload contracts, automatic function parameter datatype mapping, and manifest packagesMapping follow-up guidance. Use when an agent must create a new package/versioned package container rather than only invoke an existing function from app runtime code.
Update Domo Code Engine packages through CLI-driven versioned lifecycle workflows with compatibility checks, datatype contract safeguards, and manifest mapping drift synchronization. Use when an agent must update package code or create a new package version and keep app mappings aligned.
| name | appdb |
| description | Toolkit-first AppDB document CRUD, query operators, and collection wiring. |
This rule is toolkit-first. Use AppDBClient instead of raw domo.get/post/put/delete endpoints.
yarn add @domoinc/toolkit
import { AppDBClient } from '@domoinc/toolkit';
type Task = {
title: string;
status: 'active' | 'completed';
priority: 'Low' | 'High' | 'Urgent';
};
const tasksClient = new AppDBClient.DocumentsClient<Task>('TasksCollection');
const created = await tasksClient.create({
title: 'New Task',
status: 'active',
priority: 'High'
});
const task = created.body;
const all = await tasksClient.get();
const active = await tasksClient.get({ status: { $eq: 'active' } });
const highOpen = await tasksClient.get({
$and: [{ status: { $ne: 'completed' } }, { priority: { $in: ['High', 'Urgent'] } }]
});
Documents returned by .get() are wrapped with metadata and your fields live inside doc.content.
What .create() accepts:
{ vendor: 'Acme', riskLevel: 'High', notes: 'Late payments' }
What .get() returns (shape):
[
{
"id": "04b1756e-7b6d-4d77-842f-7975a6474d8a",
"datastoreId": "a3b85171-...",
"collectionId": "ba194a7d-...",
"syncRequired": true,
"owner": 767612617,
"createdOn": "2026-03-22T02:22:42.030Z",
"updatedOn": "2026-03-22T02:22:42.030Z",
"updatedBy": 767612617,
"content": {
"vendor": "Acme",
"riskLevel": "High",
"notes": "Late payments"
}
}
]
Key points:
doc.content, not at the top level.doc.id is the document ID used for .update() and .delete().datastoreId, collectionId, owner, createdOn, etc.) are top-level.response.body or directly the array.Required parsing pattern:
const response = await tasksClient.get();
const rawDocs = response.body || response;
const docs = Array.isArray(rawDocs) ? rawDocs : [];
const parsed = docs.map((doc) => ({
id: doc.id,
...doc.content
}));
Common mistake:
// WRONG: fields are inside content
const docs = response.body || response;
docs[0].vendor; // undefined
// CORRECT
docs[0].content.vendor; // "Acme"
await tasksClient.update({
id: 'document-uuid',
content: { title: 'Updated', status: 'completed', priority: 'Low' }
});
await tasksClient.partialUpdate(
{ status: { $eq: 'active' } },
{ $set: { status: 'archived' } }
);
await tasksClient.delete('document-uuid');
await tasksClient.delete(['uuid-1', 'uuid-2']);
Collections still must exist in manifest.json under collections.
{
"collections": [
{
"name": "TasksCollection",
"schema": {
"columns": [
{ "name": "title", "type": "STRING" },
{ "name": "status", "type": "STRING" }
]
}
}
]
}
collections mapping exists in manifestAppDBClient.DocumentsClient used for CRUD.get() results are unwrapped from doc.content before UI/use$eq, $in, $set, $inc, etc.) used correctly