Highlights
- Add several supporting files to one Assistant message.
- Dictate an Assistant request and review the resulting text before sending it.
- Define more explicit Endpoint input and output fields.
- Apply ordered, bounded data transformations in low-code logic.
- Move between Endpoint, Job, history and plugin work with less context switching.
In detail
Build a complete request from the material that matters
Build a complete request from the material that matters
An Assistant conversation can now carry multiple attachments. A builder investigating an import issue, for example, can attach a sample file, an export and a written description to the same request instead of splitting context across messages. The conversation retains the relationship between the question and the material supplied with it.Voice capture adds another way to start that workflow. Dictate a short instruction, check the captured text, make any needed correction and submit it as a normal message. It is useful while inspecting configuration or execution evidence. Attachments and dictated input do not expand access to files, data or actions: the task continues to use only material and capabilities available in its application context.
Describe what an Endpoint expects and returns
Describe what an Endpoint expects and returns
Endpoint configuration now has a stronger contract surface for request and response fields. Rather than making a caller infer every payload detail from implementation, a builder can state expected structure at the Endpoint boundary and shape the result for consumers. This makes an Endpoint easier to connect from a UI component, an automation or another service because its intended input and output are visible where it is configured.The practical benefit is control over the hand-off between application layers. A team can preserve a structured response where a client needs separate fields, merge a calculated result with existing response data where that is the right contract, and avoid accidental casing changes when an existing consumer depends on a name. These are configuration choices, not replacements for validation or authorization; an Endpoint still executes under its normal rules.
Make routine data changes readable
Make routine data changes readable
Low-code data work gains an ordered update form for common transformations. A definition can apply a small sequence such as setting a workflow value, adding to a numeric counter, normalising text and then updating a selected JSON property. Operations run in written order, which matters when later work depends on an earlier result.The form is designed for precise, bounded edits. It supports literal values and explicit arithmetic, text, date and JSON-path operations; it is not an invitation to hide an unreviewed general-purpose query in application logic. Limits and surrounding data permissions continue to apply. Routine operational changes can therefore stay legible in the definition, while complex business rules remain in the appropriate component or Endpoint.
Keep the operational workspace in view
Keep the operational workspace in view
The editor and related operational views were refined around the way teams move through a task. While working on an Endpoint or Job, users can keep configuration, code-oriented editing, execution samples, event history and related plugin details within the same broader workspace. It reduces the need to rediscover the object that explains why a run behaved as it did.These changes complement the established platform flow: define a resource, test it with realistic input, inspect execution evidence and adjust the definition with the relevant context available.
Also in this release
- Assistant and resource views received focused navigation and presentation refinements.
- Endpoint configuration supports richer schema-oriented choices.
- Managed V8 runtime authoring declarations were expanded for the new data-update form.