Hello,

I do not think that is possible. What you are trying to do is control the input midway. As soon as the process starts, an instance is created with the passed JSON parameter, for example { name: "test", age: 28 }. That becomes the instance. Once you want to modify it, in case of errors such as missing mandatory attributes or validation errors, you would have to create another instance, in other words, rerun the process.

Thanks for the inputs.

Hi @Padmakumar S ,

Assuming this is an OutSystems BPT process step that consumes an external REST API and then parses/deserializes the response JSON, I’d focus on making the payload-reading stage resilient. When the failure is invalid JSON, this should be treated as a data/payload error, not as a transient technical failure.

Below is a concrete recommended design pattern.

Recommended design (REST consumption + internal queue + controlled reprocess)

1) Persist every inbound payload in an internal “queue” entity

Instead of calling the REST API and immediately processing everything inside the same process path, store the raw payload first. Create an entity like Integration_InboundMessage (name is illustrative) with fields such as:

• Id
• SourceSystem / EndpointName
• CorrelationId / RequestKey (if applicable)
• ReceivedOn
• HttpStatusCode
• RawPayload (Text) - store the JSON exactly as received
• Status (e.g., New, ReadyToParse, InvalidPayload, Processed, Failed)
• AttemptCount (even if you’re not focusing on retry, this is useful for reprocess tracking)
• LastErrorMessage
• LastErrorCategory (e.g., InvalidJson, MappingError, Other)

This gives you traceability and prevents “losing” the payload when parsing fails.

2) Split into two stages: Fetch vs Parse/Process

• Stage A: Fetch
  • Call the REST API.
  • Save RawPayload + metadata into the queue entity.
  • Mark as ReadyToParse (or New).
• Stage B: Parse + Business Processing
  • A separate process step (or a dedicated processing flow) picks up records in ReadyToParse.
  • It attempts deserialization and processing.
  • On success: mark as Processed.
  • On JSON failure: mark as InvalidPayload and store the error details.

This avoids having your “main” process instance permanently fail just because one payload is malformed.

3) Classify invalid JSON as Data Error and quarantine it

If parsing fails due to invalid JSON:

• do not keep retrying the same parse blindly
• do not require re-triggering the full process manually
• instead, quarantine the record as InvalidPayload with:
  • raw payload
  • parsing error message
  • timestamp
  • optional provider version / endpoint info

4) Add a “payload correction / identification rules” step

To reduce manual work over time, implement a step that tries to identify and fix known payload anomalies before deserialization.

Recommended approach:

• Maintain a list of rules, each rule handling one root cause.
• If a single error can happen for multiple reasons, create one rule per reason.
• Keep rules isolated, testable, and versioned.

This helps long-term maintenance because the same root cause can reappear later (or evolve slightly), and you only need to update the relevant rule.

Examples of rule categories (illustrative):

• removing BOM / leading non-JSON characters
• normalising incorrect escaping
• removing trailing commas
• fixing known incorrect quoting for specific fields

5) Controlled reprocess (after correction)

Reprocessing should be controlled and auditable:

• after applying a correction (manual or automatic rule), set the record back to ReadyToParse
• rerun only the parse/process stage for that message

This is safer and cleaner than re-triggering an entire BPT instance “from scratch”.

If you need more help, share the expected JSON schema and how you currently deserialize it, and I can suggest a concrete rule structure (including where to implement it and how to keep it maintainable).

Regards,

Hi @Padmakumar S 

Instead of letting the process fail and "Active with Error," you can design the process to pause and wait for a fix. 

Don't pass the JSON directly as a process input. Instead store the raw JSON in a Queue/Stagng Entity, then Start the BPT based on the creation of this record and Inside the BPT, use a Wait Activity or a Human Activity if the parsing fails.