Was toying around with the unsurpassed data table component for flow by @Eric Smith and found two things which are perhaps nice to share with the community:
1. After trying a bit I found it is possible to add 'dummy' records in a flow to the collection displayed in a table. When would that be useful? For example when you want to display a project schedule overview including empty dates without activities for example (see screenshot). This does require you to use a dummy record id.
This record id has to be of the same object but can be lengthened. For example with the number of the counter in a loop. It does not matter how long the id is, as long as it is unique within the record set displayed by the table. (I have not dived into the code, but the data table seems to use the first part of the id to decide what kind of object it is dealing with?).
2. Creating dummy records and 'shallow' copies for activities spending multiple days does render the option to automatically link the name to the record useless because it now links to fake record id's. Luckily you can change field labels in the data table too. During the process of creating a formula link to serve as the link to the record instead, I tried some url-hacking. After experimenting a bit I found you can actually have an edit modal pop-up right from the table, with the flow table still there in the background! All it requires is that you create a text formula field with the following formula:
HYPERLINK("/lightning/r/ObjectName__c/" & Id & "/edit?layoutType=FULL&backgroundContext=", Name, "_self")
ObjectName__c should obviously be replaced by the name of the object of your liking, and possibly you also want another text field instead of the Name field (e.g. could be a static 'Edit' too).
After some tweaking, you can end up with something looking like the pictures attached!
What is there to wish for:
- With longer periods or complex flows in general you will hit the maximum of 2000 iterations easily. It would be great if that limit would be higher! I hope there is no technical debt that prevents flows from scaling up to apex capabilities in that respect (since they were probably not designed to do massive database manipulations in the first place)...
- For interface enhancement scenarios supplied via flow it would be great to have a refresh option that does not require a complete rerender of the flow. This seems difficult in the context of flow however: the soql happens in the context of the execution of the flow and not through the wire service.
@Alex Burns nice to read your use-case! I did something like that too when I needed a quick timesheet app. It creates a (partly prefilled) row for every day in a period the user selects. @Eric Smith in this case it was a bit bothersome that we can only return either selected or edited rows btw. I can imagine why that wouldn't be necessary if you pass a 'normal' collection to the table. But in these scenarios with 'dummy' records, it could be useful actually!