What

Adds complex (template) field mappings , template / prefix / transformations , to the update_crm_field_mappings config-write change, so a user can shape what Cedar pushes to their CRM through the tool (editing their own connection) instead of hand-editing connection metadata.

Motivating use case: prepend a date stamp to Salesforce next steps , e.g. 8/19: Follow up with procurement , so a manager can see next-step freshness in their forecast view. Achieved with template:"{nextSteps}", prefix:"{today}: ", transformations:{today:{type:"date",format:"M/d"}}.

Why this is small

Everything downstream already supported complex mappings , the push mapper (mapCedarFieldsToCrm) evaluates template/prefix/transformations and applies the prefix idempotently, and CrmFieldMappingSchema already validates the complex shape. The config-write path just never exposed those fields. So this is plumbing only: no runtime/mapper change, no DB migration (fieldMappings is JSONB).

Because the MCP config-write tool reuses the exact exported ConfigChange union, the schema is edited in one place and both surfaces inherit it.

Changes

• external-crm-field-mapping.ts , export FieldTransformationSchema so the tool reuses the exact transform shape (no re-declare/drift).
• applyConfigChangeTool.ts , add optional template / prefix / transformations to update_crm_field_mappings; thread them through; document in the change + tool description.
• connection-config.ts (updateCrmFieldMappings):
  • require cedarFieldName XOR template (complex mappings identify their field via {placeholder} tokens, not cedarFieldName);
  • reject prefix/transformations without a template;
  • build a clean mapping and strip cross-shape keys on conversion, so a simple→complex change can't leave a stale cedarFieldName behind (and vice-versa);
  • preserve partial-update merge semantics (e.g. toggling pushEnabled keeps an existing allowedValues);
  • validate the final mapping against CrmFieldMappingSchema before persisting , the first write-time validation on this path.
• tests , simple→complex conversion asserts the stored shape and that cedarFieldName is dropped; and that prefix without template is rejected.

Testing

• Scoped vitest: applyConfigChangeTool.test.ts 10/10 pass (2 new).
• Server typecheck clean.

🤖 Generated with Claude Code

Greptile Summary

This PR exposes complex CRM template mappings through the account config-write tool and adds shared-schema validation during persistence.

• Adds template, prefix, and transformation inputs to update_crm_field_mappings.
• Supports conversion between simple and complex mapping shapes while preserving partial-update properties.
• Exports the shared transformation schema and adds focused tool tests.
• Complex placeholder names still need semantic validation before mappings are saved.

Confidence Score: 4/5

The PR should not merge until complex template placeholders are validated, because a typo can be accepted and then silently prevent the intended CRM update.

The new write surface persists arbitrary template placeholders even though the downstream mapper only acts on recognized Cedar fields; the relative import is an additional non-blocking convention issue.

Files Needing Attention: apps/server/src/services/integrations/connection-config.ts; apps/server/src/mastra/skills/account-config/tools/applyConfigChangeTool.ts

Important Files Changed