NetworkId and custom column names add

[cadillacben]

I'm only a beginner developer and have almost no idea how to use github, so we can start with that. :) I tried but can't get some lines to match which I assume is some tab vs. space thing.

I was trying to use this for community users and found I needed to add the NetworkId to make this work. All I did was to add that as an input and add the bit below. In my flow I get the $User's NetworkMember.NetworkId to use as the input, but there could be a better way to do that.

I then realized that the csv spits out with column names set to field API names, which caused issues for me. My updates there are not elegant, but work for me.

The test class does need to be updated to pass in the networkId string, but can just be '' from what I found.

[alexed1]

the pull request looks great. So long as it's easy for others to spot the changes you've made, it's ok if a few lines are marked needlessly as changes.

I'm not quite clear on the two changes. Example: Is the NetworkId required when you're exporting User records? or are you talking about the user that's running the flow? Can you draft a simple Google Doc that we could use to create a blog post? A few images/examples would be great.

[cadillacben]

@alexed1 I created the below doc to help explain my updates. I'm not the best writer, so feel free to reword.

NetworkId on ContentVersion if the current user is a community user, so that was a simple input add overall.

The other change was to add custom column labels. My solution is simple because it's all I knew how to do, but probably could be improved upon.

https://docs.google.com/document/d/1WCFhnXXUP9SrtZYRrcfewVtFSYtjfGq5XIcfs15xuB8/edit?usp=sharing

Let me know if anything else is needed.

[alexed1]

It sounds like this change would require the user to provide both a list of field names and now a list of labels. Currently you don't need to provide labels. I've asked @cadillacben to explore whether the ability to provide labels can be made optional.

[cadillacben]

It sounds like this change would require the user to provide both a list of field names and now a list of labels. Currently you don't need to provide labels. I've asked @cadillacben to explore whether the ability to provide labels can be made optional.

Although I think this is possible, unfortunately I'm not skilled enough to know how to do it. I'd think we'd add some checks to see if columns were specified and process differently overall. I think I tried this a bit, but failed. :(

I also don't know if there's similar validation on the inputs kinda like the required ones so the user sees it when saving the action.

[alexed1]

I know we kinda let this one slide, but I'm reluctant to lose it. I don't mind if new users of this action have to know to use columnsString if they use fieldsString, but I'm worried about existing implementations. I think that they might all break because they have null columnsString? That's the only lingering issue here...

[cadillacben]

I know we kinda let this one slide, but I'm reluctant to lose it. I don't mind if new users of this action have to know to use columnsString if they use fieldsString, but I'm worried about existing implementations. I think that they might all break because they have null columnsString? That's the only lingering issue here...

I do agree. Maybe someone with more dev skills can work that out. Maybe a boolean field to indicate custom columns/fields, but I know I can't do it at least not well/efficiently.
I actually stopped using this one and did it via a platform event that is heard by our boomi system. That converts the data into xlsx (what the business wanted) and isn't hindered by limits I was hitting. It all worked out. :)

[AndyHaas]

I will put this one on my list to look into and see if we can get these added. I don't see the exact changes, so if @cadillacben can share the code changes, that would be fantastic.