{
  "skill_name": "workfront-planning-advisory",
  "evals": [
    {
      "id": 1,
      "name": "Plain limit question",
      "prompt": "What's the max number of records per record type in Workfront Planning?",
      "expected_output": "Answers 25,000, notes the roadmap target of 50,000 initially rather than unlimited, and states that this cap is the same across all tiers.",
      "files": [],
      "assertions": [
        "States the 25,000 records-per-record-type cap",
        "Notes the roadmap target is 50,000 initially, not unlimited",
        "Notes this particular cap does not vary by tier",
        "Reads references/limits-and-tiers.md rather than quoting a number from memory",
        "Does not claim the limit is unlimited"
      ]
    },
    {
      "id": 2,
      "name": "Customer asking for a limit exception",
      "prompt": "A large enterprise customer is asking us to raise the 500 connected records limit to 2,500. They've hit it on day one of go-live. What should I tell them?",
      "expected_output": "Reframes the request as an architecture problem rather than a limit problem, notes that the projected volume would exhaust even a raised cap within a couple of quarters, and offers customer-ready framing language.",
      "files": [],
      "assertions": [
        "Cites the 500 connected-records cap and treats hitting it on day one as a design signal",
        "Recommends redesigning the record model before pursuing an exception",
        "Points out that a raised cap would be exhausted again within a couple of quarters at the customer's projected volume",
        "Notes that the 500 cap applies to multi-select non-hierarchy connections and does not change by tier",
        "Loads references/limits-and-tiers.md and references/customer-conversation-framings.md",
        "Does not negotiate an intermediate number such as 1,500",
        "Does not concede that the limit is generally negotiable"
      ]
    },
    {
      "id": 3,
      "name": "Customer asking for P95 data",
      "prompt": "A customer is meeting with us tomorrow and wants P95 performance numbers for Planning. What can we share?",
      "expected_output": "Explains that Adobe publishes no public P95 or SLA, and that internal numbers may only be shared framed explicitly as observed production telemetry.",
      "files": [],
      "assertions": [
        "States that Adobe does not publish a public P95 or SLA for Planning",
        "Frames any internal numbers as observed production telemetry, server-side",
        "Explicitly distinguishes telemetry from a contractual guarantee",
        "Advises how to frame the numbers if they are shared externally",
        "Does not present the numbers as a commitment or suggest they can go into a contract"
      ]
    },
    {
      "id": 4,
      "name": "RPM industry comparison",
      "prompt": "A customer is comparing our 200 RPM API rate limit to other SaaS APIs and saying it's low. How do I defend it?",
      "expected_output": "Explains that 200 RPM per user is defensible for an interactive planning product, identifies bulk integrations sharing interactive user accounts as the real trap, and recommends separate service accounts for bulk traffic.",
      "files": [],
      "assertions": [
        "States the 200 RPM per-user rate limit and why it suits interactive use",
        "Identifies bulk integrations sharing user accounts with interactive use as the actual problem",
        "Recommends separate service accounts for bulk traffic instead of raising the limit",
        "Does not benchmark against high-frequency data APIs, which are a different product category"
      ]
    },
    {
      "id": 5,
      "name": "Tier-aware limit question",
      "prompt": "What are the object limits for Workfront Planning, and do they differ by tier?",
      "expected_output": "Explains that most object limits are identical across Select, Prime, and Ultimate, and that only records per workspace and total records per instance vary by tier. Distinguishes numeric caps from package-dependent feature availability.",
      "files": [],
      "assertions": [
        "Names the Select, Prime, and Ultimate tiers",
        "States that only records per workspace and total records per instance vary by tier, and that the per-object limits are the same on all tiers",
        "Answers directly for limits that do not vary by tier, and asks which tier only for records per workspace or total records per instance",
        "Reads references/limits-and-tiers.md rather than guessing limit values",
        "Does not infer that all features are available on every package from shared numeric limits"
      ]
    },
    {
      "id": 6,
      "name": "Workspace design from scratch",
      "prompt": "Help me design a Workfront Planning workspace for a global marketing team that runs campaigns across 30 countries with multiple channels and brands.",
      "expected_output": "Proposes a multi-workspace design with a central taxonomy hub, separates work record types from reference record types, and avoids the known deviations of the Fréscopa exemplar.",
      "files": [],
      "assertions": [
        "Separates work record types (Campaigns, Tactics, Experiences) from reference types (Countries, Channels, Brands, Audiences)",
        "Proposes a central taxonomy hub rather than duplicating shared lists across workspaces",
        "Recommends 2 to 3 configured views per work record type",
        "Keeps sections within the 3 to 6 per workspace range",
        "Loads references/workspace-build-playbook.md and references/best-practice-template.md",
        "Does not put lifecycle fields on pure reference types",
        "Does not propose a single mega-workspace for all 30 countries",
        "Does not reproduce the Fréscopa template wholesale"
      ]
    },
    {
      "id": 7,
      "name": "Record type or field",
      "prompt": "We have 'Priority' and 'Campaign Sponsor' as concepts in Workfront Planning. Should they be record types or fields on Campaign?",
      "expected_output": "Applies the heuristic: Priority is a single-select field with fixed values and no data of its own; Campaign Sponsor depends on whether sponsors carry attributes worth tracking.",
      "files": [],
      "assertions": [
        "Recommends Priority as a single-select field rather than a record type",
        "Makes Campaign Sponsor conditional on whether sponsors have attributes worth tracking",
        "Explains the underlying heuristic rather than only giving the verdict",
        "Does not reflexively model both concepts as record types"
      ]
    },
    {
      "id": 8,
      "name": "Misclassified reference type",
      "prompt": "In our reference template we have a 'Pillars' record type with Status, Start Date, and End Date fields. Is that right?",
      "expected_output": "Flags that Pillars is likely misclassified as a reference type when it carries lifecycle attributes, and recommends either reclassifying it or removing the lifecycle fields.",
      "files": [],
      "assertions": [
        "Identifies that lifecycle fields on a reference type indicate misclassification",
        "Recommends moving it to a work or activity type, or removing the lifecycle fields",
        "Cites this as a known deviation in the Fréscopa template rather than an endorsed pattern",
        "Does not approve the structure merely because the reference template contains it"
      ]
    },
    {
      "id": 9,
      "name": "Specify a complete workspace build",
      "prompt": "Specify a Q1 campaign workspace build for Workfront Planning. Marketing team running 4 product lines, 5 regions, and 3 audience segments.",
      "expected_output": "Produces a complete build specification in the canonical order (workspace, sections, record types, fields, connections, sample records, views), presented once at the end.",
      "files": [],
      "assertions": [
        "Follows the build order: workspace, sections, record types, fields, connections, sample records, views",
        "Specifies each record type fully before moving to the next",
        "Includes 2 to 3 views per work record type",
        "Refers to objects by display name rather than raw IDs",
        "Presents the finished design once instead of narrating each intermediate step",
        "Does not stop after specifying only the workspace shell"
      ]
    },
    {
      "id": 10,
      "name": "CASE function availability",
      "prompt": "Is the CASE function supported in Workfront Planning formula fields?",
      "expected_output": "Answers yes, notes that the public documentation omits CASE, and treats observed API behavior as canonical over the public formula docs.",
      "files": [],
      "assertions": [
        "Confirms CASE is supported",
        "Notes that public documentation omits it",
        "Treats observed API behavior as canonical over the public formula docs",
        "Does not conclude the function is unsupported merely because the public docs omit it"
      ]
    },
    {
      "id": 11,
      "name": "Formula authoring and unsupported functions",
      "prompt": "My Workfront Planning formula field keeps failing. I'm trying to use SWITCH to map status values. Also, write me a formula for budget variance percentage between Total Budget and Actual Spend.",
      "expected_output": "Identifies SWITCH as unsupported, suggests CASE instead, and produces a variance formula using curly-brace field references with exact display names, noting decimal storage.",
      "files": [],
      "assertions": [
        "States that SWITCH is not supported in Planning formulas",
        "Suggests CASE as the supported alternative",
        "Wraps field display names in curly braces with exact case and spacing",
        "Produces a correct variance expression against Total Budget",
        "Notes that percentage values are stored as decimals, where 0.15 represents 15 percent",
        "Does not use other unsupported functions such as FORMAT or ADDHOUR"
      ]
    },
    {
      "id": 12,
      "name": "Compound API filter",
      "prompt": "How do I search for active Workfront Planning campaigns in EMEA launched after Jan 1 via the API?",
      "expected_output": "Builds a v2 filter with operator AND and conditions, ISO 8601 dates with Z timezone, and HAS_ANY_OF for the reference field. Uses IS_ANY_OF if Region is single-select instead.",
      "files": [],
      "assertions": [
        "Explicitly identifies the API version and defaults to v2 for a new direct integration",
        "Uses v2 filter.operator and filter.conditions with uppercase condition tokens, not UI labels",
        "Combines conditions with AND",
        "Uses ISO 8601 dates with a mandatory Z timezone",
        "Uses HAS_ANY_OF and record IDs for a reference Region, or IS_ANY_OF and option values for a single-select Region"
      ]
    },
    {
      "id": 13,
      "name": "Hierarchy depth limit",
      "prompt": "A customer wants Campaign > Tactic > Experience > Asset > Component in Workfront Planning. Five levels. Can we do that?",
      "expected_output": "Explains the 4-level hierarchy cap, recommends building at 3 levels to retain headroom, and suggests non-hierarchy connections for the remaining layer.",
      "files": [],
      "assertions": [
        "States the 4-record-type hierarchy depth cap",
        "Recommends building at 3 levels to preserve headroom",
        "Suggests non-hierarchy connections for the layer beyond the cap",
        "Does not tell the customer that five levels can simply be configured"
      ]
    },
    {
      "id": 14,
      "name": "Bidirectional vs unidirectional connection",
      "prompt": "Should the connection from Tactic to Campaign in Workfront Planning be bidirectional?",
      "expected_output": "Yes for parent-child: a reference field on the child pointing to the parent, with backField so the children surface on the parent record.",
      "files": [],
      "assertions": [
        "Recommends a bidirectional connection for the parent-child relationship",
        "Specifies backField as the mechanism that surfaces children on the parent",
        "Places the reference field on the child record type",
        "Does not recommend a unidirectional connection for a parent-child relationship"
      ]
    },
    {
      "id": 15,
      "name": "Automation surface selection, internal trigger",
      "prompt": "We have Workfront Workflow bundled with Planning. When a Campaign moves to Status=Approved I want to auto-create a Workfront Project. Which automation surface should I use?",
      "expected_output": "Recommends a native field-value-change automation for the bundled customer, notes the sysadmin-only authoring requirement and the no-post-save-edit constraint. Does not recommend Workflow object creation for standalone Planning.",
      "files": [],
      "assertions": [
        "Recommends the native field-value-change automation surface",
        "Notes that authoring requires a system administrator",
        "Notes the constraint that the action cannot make post-save edits",
        "Loads references/synthesized/automations-deep-dive.md",
        "Does not recommend Fusion for a case native automation handles",
        "Does not imply Workfront Project creation is available to standalone Planning customers"
      ]
    },
    {
      "id": 16,
      "name": "Automation surface selection, external trigger",
      "prompt": "I want to auto-update a Workfront Planning record when a row changes in our external CRM. Which automation surface?",
      "expected_output": "Recommends Fusion, because the trigger originates outside Planning and native automations cannot respond to external events.",
      "files": [],
      "assertions": [
        "Recommends Fusion",
        "Explains that native automations cannot be triggered from outside Planning",
        "Mentions Fusion's execution history as an observability benefit",
        "Does not recommend a native automation for an external trigger"
      ]
    },
    {
      "id": 17,
      "name": "AI Assistant scope",
      "prompt": "What's the difference between the Planning AI Assistant and the Workfront AI Assistant?",
      "expected_output": "Distinguishes the Planning-scoped surface from the Workfront-wide surface, and notes that the beta Planning Designer is a third, separate thing. Explains Coworker's phased replacement of AI Assistant, read-only default, and admin-granted write access.",
      "files": [],
      "assertions": [
        "Distinguishes the Planning-scoped assistant from the Workfront-wide assistant",
        "Notes that the beta Planning Designer for workspace generation is separate from both",
        "Mentions that plan-tier gating applies to retained AI Assistant",
        "Explains phased Coworker replacement without claiming all tenants are migrated",
        "Retains AI Assistant guidance for excluded industries and unmigrated tenants",
        "States Coworker is read-only by default and writing requires administrator-granted access",
        "Names Planning Designer, not AI Designer, as a separate Beta requiring an accepted agreement",
        "Does not conflate Assistant, Coworker, and Planning Designer"
      ]
    },
    {
      "id": 18,
      "name": "GenStudio Brand connection",
      "prompt": "How do I connect a Workfront Planning workspace to a GenStudio Brand?",
      "expected_output": "Explains the connection, noting that the API connection key is Brand while the UI picker shows it under \"Adobe Applications\", and that Activations are read-only from Planning's perspective.",
      "files": [],
      "assertions": [
        "Notes that the API connection key is Brand",
        "Notes that the UI picker surfaces this under \"Adobe Applications\"",
        "States that Activations are read-only from Planning's perspective",
        "Does not confuse the API Brand key with the customer-facing GenStudio terminology"
      ]
    },
    {
      "id": 19,
      "name": "Planning reporting expectations",
      "prompt": "Can we build a report in Workfront that lists all Planning Campaigns by region?",
      "expected_output": "Explains that Canvas Dashboards is the only Workfront-native surface treating Planning record types as base entities, that legacy Workfront reports cannot, and sets expectations about Canvas's beta state.",
      "files": [],
      "assertions": [
        "States that Canvas Dashboards is the only Workfront-native path treating Planning record types as base entities",
        "States that legacy Workfront reports cannot report on Planning records this way",
        "Notes the beta status and its prerequisites or exclusions",
        "Runs scripts/search.js and fetches the live Experience League page rather than relying on a bundled copy",
        "Does not suggest this works in legacy Workfront reporting"
      ]
    },
    {
      "id": 20,
      "name": "Sharing entity cap",
      "prompt": "Can I share a Workfront Planning record type with 200 users individually?",
      "expected_output": "Notes the 100 sharing entities per WFP object cap and recommends teams, or groups if Workflow is bundled; standalone sharing supports users and teams, not groups, roles, or companies.",
      "files": [],
      "assertions": [
        "States the 100 sharing entities per WFP object cap",
        "Recommends teams, or groups only after establishing that Workflow is bundled",
        "Does not recommend groups, roles, or companies for standalone Planning",
        "Does not answer with the cap alone and no workaround"
      ]
    },
    {
      "id": 21,
      "name": "Fusion modules for Planning",
      "prompt": "What Fusion modules are available for Workfront Planning?",
      "expected_output": "Lists the Watch Events trigger plus the CRUD and search modules, and explains when Fusion is the right surface versus native automations.",
      "files": [],
      "assertions": [
        "Mentions the Watch Events trigger module",
        "Mentions the CRUD and search modules",
        "Explains when to prefer Fusion over native automations",
        "Runs scripts/search.js for the Fusion modules documentation"
      ]
    },
    {
      "id": 22,
      "name": "Calendar view limitations",
      "prompt": "Can I group records by Owner in a Workfront Planning Calendar view?",
      "expected_output": "Answers no. Calendar supports filters only, with no grouping or sorting, and recommends Table or Timeline when grouping is required.",
      "files": [],
      "assertions": [
        "Answers no without hedging",
        "States that Calendar supports filters only, with no grouping or sorting",
        "Recommends Table or Timeline view when grouping is needed",
        "Notes that Timeline and Calendar require date fields"
      ]
    },
    {
      "id": 23,
      "name": "Request form approval gate",
      "prompt": "In Workfront Planning, how do I gate request submissions with an approval before a record is created?",
      "expected_output": "Explains the approval mechanism on request forms, including default versus custom rules, first-match resolution, and who can be an approver.",
      "files": [],
      "assertions": [
        "Explains that the request form is the gate between submission and record creation",
        "Describes default versus custom approval rules with first-match resolution",
        "Notes that approvers can hold any license tier",
        "Runs scripts/search.js for the request form and approval documentation"
      ]
    },
    {
      "id": 24,
      "name": "Template adoption review",
      "prompt": "A customer wants to instantiate the Fréscopa template for their marketing org. Anything I should flag?",
      "expected_output": "Leads with the strong architectural patterns, then surfaces the documented deviations so the customer adopts consciously rather than blindly.",
      "files": [],
      "assertions": [
        "Leads with strong patterns such as the central taxonomy hub, lookup-rich work records, and hierarchy design",
        "Surfaces the known deviations, including lifecycle fields on reference types, the views coverage gap, single-section workspaces, naming typos, the 4-level hierarchy ceiling, missing business rules, and the 500-connection sizing risk",
        "Recommends the customer decide on each deviation consciously",
        "Loads references/best-practice-template.md and references/customer-conversation-framings.md",
        "Does not present the template as turnkey or skip the deviations"
      ]
    },
    {
      "id": 25,
      "name": "Public docs versus API behavior",
      "prompt": "The public Workfront Planning docs say currency fields support 6 decimal places, but my API call only accepts 4. What's going on?",
      "expected_output": "Explains that observed API behavior is authoritative for API questions, that 4 decimals is the actual accepted precision, and that the public docs are likely outdated.",
      "files": [],
      "assertions": [
        "States that the API accepts 0 to 4 decimals",
        "Treats observed API behavior as authoritative for the API question",
        "Notes the public documentation is likely outdated on this point",
        "Points to references/public-vs-api-discrepancies.md",
        "Reports the discrepancy rather than silently picking one source",
        "Does not insist the public docs are correct and the API is broken"
      ]
    },
    {
      "id": 26,
      "name": "Internal versus external framing",
      "prompt": "I'm presenting Workfront Planning performance numbers to internal leadership. What should I say?",
      "expected_output": "Confirms internal telemetry is appropriate for leadership context when framed correctly, and warns against repackaging the same numbers into customer commitments.",
      "files": [],
      "assertions": [
        "Confirms internal telemetry is fair game for an internal leadership audience",
        "Anchors the framing words: observed, production, server-side",
        "Warns that the same numbers must not be repackaged as customer SLA commitments"
      ]
    },
    {
      "id": 27,
      "name": "Documentation lookup for an uncovered topic",
      "prompt": "How do notifications work in Workfront Planning, and can users control what they receive?",
      "expected_output": "Uses the bundled search to find the relevant Experience League pages, fetches the live page, and supplements with the synthesized notification reference.",
      "files": [],
      "assertions": [
        "Runs scripts/search.js with notification-related keywords",
        "Fetches the live Experience League page from the returned URL rather than answering from memory",
        "Consults references/synthesized/notification-preferences.md",
        "States clearly if the reference set does not cover part of the question rather than inventing behavior"
      ]
    },
    {
      "id": 28,
      "name": "Design question mentioning volume is not a limits question",
      "prompt": "We run about 30 country programmes, each with several hundred tactics a year, and marketing wants everything linked back to one campaign record. How should I model this in Workfront Planning?",
      "expected_output": "Answers the modelling question: work versus reference record types, a hierarchy or intermediate record type rather than one parent connected to everything. Raises the 500-connection cap only as a consequence of the proposed shape, not as the headline.",
      "files": [],
      "assertions": [
        "Treats this as a workspace design question and answers how to model it",
        "Recommends a hierarchy or intermediate record type instead of connecting everything to a single campaign record",
        "Loads references/workspace-build-playbook.md rather than leading with references/limits-and-tiers.md",
        "Mentions the 500-connection cap only as a consequence of the proposed design, not as the opening answer",
        "Does not answer with a list of object limits",
        "Does not ask which tier the customer is on, since no tier-dependent limit is involved"
      ]
    },
    {
      "id": 29,
      "name": "New integration defaults to v2",
      "prompt": "We are building a new direct Planning API integration. Which version should we use, and what did the v2 release add?",
      "expected_output": "Recommends v2, notes v1 remains available, and describes the capabilities announced in the release notes.",
      "files": [],
      "assertions": [
        "Recommends v2 for a new direct integration while noting v1 remains available",
        "States API v2 became available to all customers May 28, 2026",
        "Mentions workspace, record-type, and field CRUD plus record management",
        "Mentions PATCH partial updates, bulk operations, and filtering or pagination improvements"
      ]
    },
    {
      "id": 30,
      "name": "Migrate a v1 OR filter",
      "prompt": "Our v1 search uses filters: [{\"$or\":[{\"Fstatus\":{\"$is\":\"Active\"}},{\"Fstatus\":{\"$is\":\"Planned\"}}]}]. Show the v2 filter for the same search.",
      "expected_output": "Preserves matching Active or Planned using v2 filter.operator OR with two IS conditions, or an equivalent IS_ANY_OF condition for a single-select status field, with resource-scoped search.",
      "files": [],
      "assertions": [
        "Matches Active or Planned using either filter.operator OR with two IS conditions on fieldId Fstatus, or a single IS_ANY_OF condition on Fstatus with value [\"Active\", \"Planned\"] for a single-select field",
        "Uses /v2/record-types/{id}/records/search",
        "Does not mix v1 dollar-prefixed operators into the v2 filter",
        "Does not claim the example was verified against a live tenant"
      ]
    },
    {
      "id": 31,
      "name": "Fusion needs a v2-only operation",
      "prompt": "Can the Planning Fusion connector create an entire workspace and its fields through v2?",
      "expected_output": "Selects a connector/version whose modules support workspace and field creation; uses authenticated HTTP or a direct v2 integration if the available connector lacks those operations.",
      "files": [],
      "assertions": [
        "Checks the available connector/version for the required operations without asserting all connectors use v1",
        "Recommends authenticated Fusion HTTP or a direct v2 API call when the available connector lacks the operation",
        "Does not claim changing a native connector setting enables v2"
      ]
    },
    {
      "id": 32,
      "name": "Restricted records preserve viewing",
      "prompt": "If I set default record permissions to Restricted, will everyone except the creator lose view access to existing and new records?",
      "expected_output": "Explains that the documented Restricted default restricts editing, not viewing, applies only to newly created records, and preserves manager/admin access.",
      "files": [],
      "assertions": [
        "States other users retain view access under the documented Restricted default",
        "Limits editing to the creator and explicitly added people while managers and administrators retain Manage",
        "States changing the default affects newly created records, not existing records",
        "Does not conflate this editing restriction with a no-view allow list"
      ]
    },
    {
      "id": 33,
      "name": "Workflow Light and Planning Standard",
      "prompt": "We have bundled Workflow and Planning with equal license quantities. Can a Workflow Light user have Planning Standard?",
      "expected_output": "Answers yes under the documented equal-quantity bundled licensing model; keeps Workflow and Planning license types separate.",
      "files": [],
      "assertions": [
        "Confirms Workflow Light can receive Planning Standard in this case",
        "Explains that a paid Workflow license is required for Planning Standard in the equal-quantity bundled case",
        "Does not treat Workflow Light as a Planning license type"
      ]
    },
    {
      "id": 34,
      "name": "Unequal bundled license quantities",
      "prompt": "Our Workflow and Planning license quantities differ. Can we assign Planning Contributor or combine license types freely?",
      "expected_output": "States the unequal-quantity bundled model allows license combinations but does not offer Planning Contributor.",
      "files": [],
      "assertions": [
        "States Planning Contributor is not available for unequal quantities",
        "Explains license combinations are otherwise flexible",
        "Does not apply the equal-quantity licensing rules indiscriminately"
      ]
    },
    {
      "id": 35,
      "name": "Standalone Workflow connection and sharing",
      "prompt": "We bought Planning as a standalone product. Design an automation to create Workfront projects, connect their records, and share the workspace with a company.",
      "expected_output": "Declines the unsupported Workflow portions, explains standalone exclusions, and offers Planning-only automation and user/team sharing rather than a Fusion workaround that bypasses entitlement.",
      "files": [],
      "assertions": [
        "States standalone customers cannot connect Workflow object types or create them through Planning automations",
        "States standalone sharing supports users and teams, not groups, roles, or companies",
        "Does not propose Fusion as an entitlement bypass",
        "Offers a Planning-only design where useful"
      ]
    },
    {
      "id": 36,
      "name": "Business rules on a global record type",
      "prompt": "Can I block edits and deletes with business rules on a global Campaign record type in either its original or secondary workspace?",
      "expected_output": "States business rules are unavailable on global record types in both contexts and distinguishes supported local-type business rules.",
      "files": [],
      "assertions": [
        "Rejects business rules on global record types in both original and secondary workspaces",
        "Explains local-type conditional editing/deletion rules without inventing rule-count limits",
        "Does not recommend Formula, Lookup, or Reference fields as rule conditions"
      ]
    },
    {
      "id": 37,
      "name": "Dependent connections and external objects",
      "prompt": "Can I make a Planning dependent connection controlled by a Workfront project or an AEM asset? What about another Planning record type?",
      "expected_output": "Rejects Workfront/AEM dependent connections and explains the existing Planning relationship and third-type prerequisites.",
      "files": [],
      "assertions": [
        "States dependent connections do not support Workfront or AEM objects",
        "Requires an existing connection between Planning record types and the source and dependent fields on the same third type",
        "States up to 3 direct controlling fields and 6 dependency connections involving up to 7 record types",
        "Explains source changes clear dependent values and does not confuse this with picker filtering or hierarchy limits"
      ]
    },
    {
      "id": 38,
      "name": "Two parent record types in one workspace",
      "prompt": "In one workspace, we want Tactics to be children of both Campaigns and Programs in separate hierarchies. Does the 10-parent limit allow that?",
      "expected_output": "Distinguishes parent records from parent types and redesigns using one hierarchy parent type plus ordinary connections.",
      "files": [],
      "assertions": [
        "States one parent record type per child type in a given workspace",
        "Explains the 10-parent cap concerns parent records, not record types",
        "Suggests ordinary connections or an intermediate design for the other relationship",
        "Does not approve two parent types based on the 10-record limit"
      ]
    },
    {
      "id": 39,
      "name": "Calendar display paging",
      "prompt": "Our Calendar week has 1,500 records but initially shows only 1,000. Did we hit a storage limit or need a higher Planning tier?",
      "expected_output": "Explains display paging across the visible week and Load more; does not confuse this with storage capacity.",
      "files": [],
      "assertions": [
        "States first 1,000 records across the visible week and Load more",
        "Distinguishes display paging from storage and records-per-type limits",
        "Does not recommend a tier upgrade solely for this display threshold",
        "Checks rollout availability for the tenant rather than claiming it is universal"
      ]
    },
    {
      "id": 40,
      "name": "Template bundle package gate",
      "prompt": "All our numeric object limits match Ultimate. Does that mean our Workflow Select package can use Planning template bundles?",
      "expected_output": "Explains template bundles require Workflow Prime or Ultimate and numeric cap parity does not imply feature parity.",
      "files": [],
      "assertions": [
        "States template bundles require Workflow Prime or Ultimate",
        "Distinguishes Workflow package gating from Planning numeric limits and user license types",
        "Does not infer template bundle availability from shared limits"
      ]
    },
    {
      "id": 41,
      "name": "Select option values after rename",
      "prompt": "Older select choices use alphanumeric values, new ones use friendly values, and I renamed a choice. Should our integration regenerate every value from the label?",
      "expected_output": "Preserves existing option values, reads actual field options, and distinguishes labels from stable API values.",
      "files": [],
      "assertions": [
        "Explains old choices retain alphanumeric values while new choices have friendly values",
        "States renaming a choice does not change its value",
        "Recommends reading field options rather than deriving all values from display labels"
      ]
    },
    {
      "id": 42,
      "name": "Sequential approvals versus revise loops",
      "prompt": "In a tenant where multi-stage approvals are enabled, we need manager approval followed by legal approval, then a revise-and-resubmit loop. Are both native?",
      "expected_output": "Supports sequential stages and distinguishes them from undocumented revise-and-resubmit loops.",
      "files": [],
      "assertions": [
        "States sequential multi-stage request approvals are supported",
        "Explains required approvers complete a stage before progressing, subject to only-one-decision and team exceptions",
        "Does not claim editing a submitted request proves native revise-and-resubmit support"
      ]
    },
    {
      "id": 43,
      "name": "Partial update and null clearing",
      "prompt": "Show how to update one v2 record data field without changing the others, then explicitly clear another writable field.",
      "expected_output": "Uses PATCH for a partial update and explicit null to clear a writable field according to its schema.",
      "files": [],
      "assertions": [
        "Uses PATCH /v2/records/{id} and only the requested data keys",
        "Uses an explicit null for clearing a writable data field",
        "Checks the writable field schema rather than generalizing clearing to read-only or computed fields"
      ]
    },
    {
      "id": 44,
      "name": "Bulk operation outcomes",
      "prompt": "We are adopting v2 bulk record operations. Can we assume every record succeeded when the request returns a successful HTTP status?",
      "expected_output": "Checks per-record outcomes rather than treating the HTTP status alone as confirmation that every record succeeded.",
      "files": [],
      "assertions": [
        "Mentions API v2 supports bulk record operations",
        "Checks the response for per-record errors",
        "Consults the operation's developer reference for request limits and response contracts"
      ]
    },
    {
      "id": 45,
      "name": "Migration pagination guidance",
      "prompt": "We are migrating record searches from v1 to v2. Can we copy our existing pagination code unchanged because the release only changed the URL?",
      "expected_output": "Explains the release includes pagination improvements and directs the caller to the endpoint's developer reference rather than assuming v1 shapes are unchanged.",
      "files": [],
      "assertions": [
        "States the v2 release includes pagination changes, not only URL changes",
        "Uses the endpoint's developer reference for the v2 pagination contract",
        "Does not assume v1 request and response shapes carry over unchanged"
      ]
    },
    {
      "id": 46,
      "name": "Coworker rollout and write access",
      "prompt": "Can we assume CX Enterprise Coworker is enabled in our Planning tenant, can it write by default, and is Planning Designer the same product?",
      "expected_output": "Checks tenant availability rather than assuming universal provisioning, describes the phased rollout, read-only default and admin write grants, Assistant retention, and separate Designer Beta.",
      "files": [],
      "assertions": [
        "Checks whether Coworker is enabled in the customer's tenant rather than assuming universal availability",
        "Describes the phased rollout and consults the availability ledger for rollout dates when needed",
        "States Coworker is read-only by default",
        "States writing requires administrator-granted access",
        "Retains AI Assistant for excluded industries or unmigrated tenants",
        "Names Planning Designer as a separate Beta requiring an accepted agreement"
      ]
    },
    {
      "id": 47,
      "name": "Duplicating constrained connections",
      "prompt": "When duplicating a record with one-to-one or one-to-many connections in a tenant with the new behavior enabled, are the links copied to both records?",
      "expected_output": "Explains the choice to keep links on the original or move them to the duplicate, with keep-on-original the default.",
      "files": [],
      "assertions": [
        "States keep on original is the default",
        "Explains the option to move connections to the duplicate",
        "Does not claim constrained links are blindly copied to both records",
        "Distinguishes the duplication choice from changing connection cardinality"
      ]
    },
    {
      "id": 48,
      "name": "Global request routing exceptions",
      "prompt": "With the new routing enabled, where do requests for a global record type create records if launched in a secondary workspace, the main Requests area, or with a Workspace field populated?",
      "expected_output": "Routes secondary-workspace submissions to that workspace, main Requests or original-workspace submissions to the original, and a populated Workspace field overrides launch context.",
      "files": [],
      "assertions": [
        "Routes secondary-workspace submissions to the secondary workspace",
        "Routes original-workspace and main Requests submissions to the original workspace",
        "States a populated Workspace field takes precedence over launch context",
        "Does not claim editing a submitted request is possible after the record has already been created"
      ]
    },
    {
      "id": 49,
      "name": "Field sharing across surfaces",
      "prompt": "With field-level sharing enabled, can someone bypass a field restriction by reading it through a connection, request form, API, or dashboard instead of a view?",
      "expected_output": "Explains field restrictions apply in views, record details, connections and lookups, dashboards, the API, MCP tools, and exports, but not on request forms or public views; formula fields expose calculated values unless restricted separately.",
      "files": [],
      "assertions": [
        "States enforcement covers views, record details, connections, API, and dashboards",
        "States request forms and public views are not covered by field sharing",
        "Does not claim request-form fields are protected by field sharing based on the older Q4 release note",
        "Notes formula fields must be restricted separately to hide calculated values",
        "Does not recommend an API or dashboard bypass",
        "Distinguishes field access from workspace or record-type sharing"
      ]
    },
    {
      "id": 50,
      "name": "Record permission override limits",
      "prompt": "A colleague has View on the record type. Can I give them Manage on one record, or remove their access to view just that record?",
      "expected_output": "Explains the documented record-sharing model does not grant above record-type permission and does not remove individual view access.",
      "files": [],
      "assertions": [
        "States record permission cannot exceed the colleague's record-type permission",
        "Does not recommend granting Manage above record-type View",
        "States individual record View cannot be removed under the documented model"
      ]
    }
  ]
}