Changelog in Kissflow

Modified 3 years ago

This is the log of all the changes in Kissflow, including scheduled changes and planned deprecations. 

Effective from March 31, 2020

Webhook payload changes 

When you send Kissflow process data to a webhook, the payload format for some widgets are changed. Now, we have matched the webhook’s payload format with the API’s payload format. 

Widget Name

Current Payload

New Payload

Currency Field


"v": 100,

"unit": "USD",

"dv": "100 USD"


"100 USD"

DateTime Field


    "v": "2020-03-06T05:15:58",

    "td": "-03:00",

    "tz": "America/Santiago",

    "dv": "2020-03-06T05:15:58Z"


User defined fields:

"2020-03-06T05:15:58-03:00 America/Santiago"

System fields:


Date Field



Child Table


[{}, {}, ...]


[{}, {}, …]


[{}, {}, ...]

Will not be available


ActivityInstance: [{}, {}, ...]


"_id": "activity_instance_id",

"Name": "step_name", 

"AssignedTo": [ {_


"Name": "Test",

Kind: "User/Group"}, ..]


Field validations changes

Kissflow will start to audit the field validation when submitting a process item through integrations or APIs. For example, if your form has required fields and field validations, they will now be verified when submitting an item via a Kissflow Integration, API, or Zapier.

Step triggers changes

When you use step triggers, only the fields visible for that particular step will be displayed for mapping.

  • When an item crosses it's deadline at this step 
  • When an item is reassigned at this step

Expect these, all the other step triggers will display the fields visible for that particular step.When you use process triggers, all the form fields will be displayed for mapping irrespective of the fields hidden under permission.  

Deprecation of step triggers

We are deprecating these step triggers

  • When an item is rejected at this step
  • When an item is sent back at this step
  • When an item is withdrawn at this step
  • Item is submitted at this step

We suggest you to use the trigger ‘When an item exits this step’ which fires in these scenarios.

  • advances to the next step
  • is sent back to a previous step
  • is rejected, OR
  • is withdrawn

You can find out which of these scenarios caused the trigger. This will be available as part of the payload information as shown in the example:


"_last_action_performed_by": [ {“_id”: "test",  "Name": "Test"} ],

"_last_action_performed_at": "2020-02-28T08:40:56Z",

"_last_action": "Reject", | “Submit”, | “Sent Back”, |“Withdraw”, | “Reassign”

"_last_action_note": "Reason for the Rejection"

"_flow_id": "ProcessId"


Did you find the article helpful?

Powered by HelpDocs (opens in a new tab)