1 person found this helpful
I had to do something similar using another CRM, and opted for a query for all workers whose parent worker Id was that of the manager (this was with Siebel, so it was Parent Position Id).
I appreciate that the manager might not be the direct manager of the worker in your case, but perhaps a ROQL query would work.
Screen 1: Select Criteria for the query and make the REST call before the Screen unloads. Load the result into a global variable.
Screen 2 : Show a custom Entity Collect with the result in a Custom Entity Collect (each row of the json response becomes a row on the Control) on mount. The user can (de)select the rows they want using a button per row (or checkbox with an EventListener) to store the value of the checkbox. You could control.removeRow(n) the offending selected rows for example.
Screen 3: You can now do with it as you wish (pass it back as an entity to OSvC, or whatever).
There's a simple example loading Excel data, transforming it to JSON, and entering it into an Entity Collect here https://theopahub.com/main/importing-data-into-an-interview-excel-example/ that might perhaps explain more clearly.
Thanks for your reply!
I was considering the REST call route, as previously mentioned. I may continue that route given your confirmation.
Have you implemented a version of this before?
I wonder if combining the text search JS extension with the REST call that filters manager's employees for dynamic lookup would be the simplest version of a solution here.
Do you have any thoughts?
P.S. The articles you wrote regarding excel loading and conversion to entity instances is fantastic! Thanks for linking the post here.
1 person found this helpful
The custom Search Extension REST call will return a nice JSON object and the commit mechanism is built around the user selecting one item from the list (so, I suppose, one employee).
I think I get what you are aiming for now - the advantage of the Search extension is that the manager can make lots of "searches" to return records, and select them each time. I suppose you could easily add each selected item to an array or an object before displaying / working with them on the next page.
What we did with Siebel (but sadly don't have access to it any more) was slightly different - we split it into several screens. The first, we gave the user a bunch of check-boxes and text boxes so they could build their "query". Then the REST call (not connected to a Search Extension, just an ajax call) was made via a Custom Label (which was actually a button marked "Search"). The data was retrieved into a JSON object.
Then the user had to click Next to see the results, displayed in a list - an Entity Collect - before they "submitted" the interview and we sent the selected people back to Siebel for processing by a Workflow.
We could get away with this because it was reasonably close to the "Click Query, make criteria, click Execute Query to see the results" paradigm of Siebel.
I'll take a look at the scenario you are suggesting and try and build out a demo - not with Service Cloud but with some other data source - it's actually the flow that I'm interested in