Steps
1. I created a very big pipeline
2. my pipeline have 8 to 10 parameters
3. I have set the default values for all those parameters and published
4. Its now very good feature when I click on Trigger Now, it takes the parameters automatically.

Also expecting below feature to improve productivity and save really good amount of time as I have many pipelines

1. Create a Tumbling/Scheduling Trigger, set the dates and when finishing again I need to add values to my 8 to 10 parameters . It does not show default set values.

Can you display the default values set when we are creating Trigger else we need to add manually all those values every time i create trigger for my pipeline,
Note: I tried with Tumbling trigger and automatic values does not show up.

The current release requires that you add activities under the If Condition or ForEach activity. If you modify an existing pipeline to add an If Condition activity, you’ll have to cut and paste all existing activities after the If Condition activity. For example, if you add an If Condition after activity A, you have to copy and paste all activities after activity A, if they are still valid and relevant after the addition, and paste them to the If Condition activity. That’s a lot of extra work. Plus, these activities are not visible on the main screen.

It would be convenient to add a new If Condition to an existing pipeline without the need to cut and paste all existing activities after the newly added If Condition activity as well as being able to see these activities on the main screen view.

I think it was a mistake to have a separate system for setting PartitionKey and RowKey values in the sink section, when you had a system setup in the translator area specifically for the purpose of translating fields (columns) when reading and writing entities. When I first tried to get a PartitionKey to come from another field in my source table (NewPKey in this example), I incorrectly tried to do it like this ...

"translator": {
"type": "TabularTranslator",
"columnMappings": "NewPKey: PartitionKey, RowKey: RowKey, Value: Value"
}
... of course, that didn't work. For logical consistency and simplicity, I wish that all field (column) translations had been done that one way.

Ok, so the team decided to have a separate system for Azure Table Storage keys. You actually specify the field from which to draw the sink entity keys using azureTablePartitionKeyName and azureTableRowKeyName.

I think you should consider changing the name of that element. It is in the docs, but it would have been helpful to have the name be more meaningful. I would suggest anything like something from the following list, which would be more meaningful ...

azureTablePartitionKeySource
azureTablePartitionKeySourceField
azureTablePartitionKeyValueSource
azureTablePartitionKeyValueSourceField
azureTablePartitionKeyDataSource
azureTablePartitionKeyDataSourceField

... and similarly for RowKey. Also, keeping in mind that when dealing with a NoSQL, schema-less storage like Azure Table Storage, we really should be using the word "field" and not the word "column." There are no columns in schema-less data, per se.

... and please fix the rollover text. The rollover text for azureTablePartitionKeyName states Azure table partition key name. Make it say something like ...

"The field to be used for each entity's PartitionKey value. Example: If you have a field named NewPKey; and you want that field to supply the values for PartitionKey in the sink dataset, then specify NewPKey for this element."