Violetta has asked for agreement from partners to make this change - PLEASE RESPOND (AGREE) ASAP
When exporting a custom report, the resulting csv file orders the columns in the same order as the ‘FIELDS’ selection when creating a custom report - see fields screenshot - but takes its feed across rows, not down one column then the next.
The outcome is a very disjointed csv file - see csv screenshot - with ‘name’ in colm G, part of the address in colm D, then more parts in colm M, then Q, all out of sequence with the actual web form.
It looks like an easy fix - reorganizing the check boxes on the custom reports ‘FIELDS’ page so they export in a sensible sequence.
I agree this requires fixing and that action would not interfere with any of my current implementations (if that’s what the team are needing Partner agreeance on?).
However, for me personally, this is not of any immediate importance over other priorities.
This is not a problem for me directly. This is mostly an issue for clients who do their own weekly reporting, and with busier campaigns, daily.
Not only do they have to get used to a new CMS, but now this hurdle is added - that requires a lot of extra work rehashing the data so they can report to their bosses - the ones that pay all our bills - so it looks somewhat clear and consistent with what they would expect anywhere else.
The bracketed ‘additions’ to the header fields are also cause great angst amongst clients.
Sorry for all the negative - bad day of shit slinging from clients.
Sorry Frog, could you please confirm that I am understanding this correctly.
At the moment the Custom Report is exporting as a CSV in alphabetical? order, and you are wanting to change it to be ordered by Case Fields then Contact Fields, then Form Fields, is this correct?
I have no quarms with this at all, seems logical to me
The Custom Report is exporting the Form Fields in alphabetical order. That’s why it goes across rows instead of down one column and then down the other column. The Contact Fields are in a logical order for going across rows. The problem is alphabetical order is usually not a logical order for Form Fields. I suggest that what you really want is to be able to put Form Fields in a customised order – perhaps the order that they appear on the form.
No, they are not exporting in alphabetical order, please look at the csv screenshot I provided. They are exporting to match the rows in the fields selection page within Custom Reports.
Yes, they should follow the way they appear in the web form.
This looks like a simple change to the layout of the field selection page within Custom Reports, to match the web form. At the moment the form fields seem very random in their placement on that page.
The spreadsheet first lists the items you’ve selected under Case Fields. Then it lists the items selected under Contact Fields. Lastly, it lists, in alphabetical order, the items selected under Form Fields. Is the data for City under Contact Fields different from Town/City under Form Fields? Likewise, it the data for Zip Code under Contact Fields different to Postcode under Form Fields? And is Contact Name under Form Fields different to First Name and Last Name under Contact Fields? If the data is the same, then selecting the Contact Fields instead of the Form Fields would give you columns in a more logical order.
The reason for using the Form fields for data that could have otherwise used Contact fields, is partly as a carry over from BC, but mainly because the colm headers need specific titles to work with New Zealand Post automatic sorting tech. This is a claims/fulfilment website, sending out rewards/prizes, thus - labels, billing, etc all derive from this data, and reports go back to the client to verify claims (full circle verification)
Ideally, the Custom Report field select page needs to reflect the Web Form, as he Workflow email does, so this should also - like it did in BC.
When the admin portal is working again, I will screenshot how it exports when those other Contact fields are selected (empty) - God knows when that will be though.