Changelog in Kissflow
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: "2020-03-06T05:15:58Z" |
Date Field | "2020-03-10T00:00:00" | "2020-03-10" |
Child Table | Model_QOVuYL1hY: [{}, {}, ...] | Table::Model_QOVuYL1h: [{}, {}, …] |
ProcessInstance | [{}, {}, ...] | Will not be available |
ActivityInstance | ActivityInstance: [{}, {}, ...] |
|
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"
}
