++1 to this, wildly agree multiple business rules should be allowed for the same trigger event type.

This would be nice, as well as a readme, I think.   What I have started doing is exporting the json and uploading it to github and managing it that way. That way we can compose readme's, have a formal change log, dif compares, etc.

The originating scenario will actually wait to proceed until it recieves a response from the secondary one, so if you need some data out of that one you can set up the secondary to respond with that data.

This is absolutely doable by leveraging the custom HTTP modules in order to call fusion webhooks.

This is maybe a bit too unwieldy, but if you haven't thought of this, you could try this.1. Pull the custom properties on your target custom form2. Repeat as many times as necessary for however many forms you want3. Create comma-seperated list string of all property names that you want values for4. ...

Unless I'm misunderstanding how CASE works, I'm not sure that would work. As an example, this:   Field value: Spanish, LA Calculation 1: es-LA Calculation 2: LA-es Calculation 3: Spanish, LATAM   While this example is made up, it's not too far from what I'm working right now, because I am integratin...

Thanks for the suggestion, Doug. Let me take a look at it.   If this works I will both be ecstatic and so angry at the same time...

Description - I would like the switch function to be added as a useable function inside of a calculated field. Why is this feature important to you - It would make coding calculated fields much easier in some circumstances. How would you like the feature to work - Just like a switch command, where ...

Which connector is this?

Good news, bad news.   The good news is, they already have ID's assigned to them.   The bad news is, nothing that is built from the Workfront front-end uses those. I do agree that it seems like there should be a way to update a field value without breaking the logic. I had a similar situation come u...