Hi Marcos,
All the event parameters are input as SNAKE_CASE. As a usability improvement and to make the user experience consistent, workflow tries to find a corresponding PascalCase attribute in an attached Entity. But when workflow can’t find a direct connection to an entity or there is no attribute corresponding to the SNAKE_CASE parameter in the entity, SNAKE_CASE parameter is provided as it is.
So, there’s no way to skip this behavior.
But what you can do is, do a check for SNAKE_CASE and SnakeCase parameter and if any of them is available, assign it to an internal variable using a script task. Then use that variable in the workflow.

 hi,

To add to this If you encounter this behavior, you can use a script task at the start of the workflow to convert the case to be more consistent 

eg:

if (execution.hasVariable('SNAKE_CASE')) {
   execution.setVariable('SnakeCase', execution.getVariable('SNAKE_CASE'));
}

Thanks for the workaround, guys. So you're saying I cannot rely on this usability improvement and should always create my own PascalCase variables because this usability improvement can fail unexpectedly? I ask that because I have this workflow triggered by an insert/update event which works on one page (Customer Order) but breaks on another (CreateOrderFromQuotationAssistant).

Unfortunately, Yes.