Hi All,
I have an interesting use case where the client wishes to open a 'Task' within a 'Case'.
For Context, we have a design where our Case has a one-to-many relationship with Tasks.
We have a 'Tasks' View on the Case record which has a selectable a!gridField where the end user can select a Task from the grid. This populates a Task screen below with data and record actions for the selected Task.
The client would like to navigate to the Case record -> Tasks View via both the a!recordLink() and a!urlForRecord() with the Task already pre-selected in the UI.
The client is not willing to have the link navigate to a Task Record as they find it confusing and do not want the User to leave the top level Case Record.
Is there any workaround I can use or is linking to a Task Record directly the only option available?
Many Thanks for your time,
Zac
Discussion posts and replies are publicly visible
Does the attached image represent your requirement or current implementation?
Hi Soma,
Apologies for the late reply, the above is our current implementation. The Client would like the above Tasks View on the Case Record to be pre-populated with a selected Task from the Tasks gridField via a a!recordLink or a!urlForRecord navigation action.
I have thought of a hacky workaround by having the Task Record mimic the Case Record exposing the same views to the end user. This way I could use the record Identifier of the Task to have it pre-selected, but I am not fond of this approach.
Hi zacc0002 ,
I have a question here. From where the user clicks the task. Is it from a separate Tasks gridfield and not inside the record? If this is the case you want to land the user in the tasks view of the case record with the selected Task pre-populated? ---> So if this is your requirement, we can't pass values to the record view in order to display the task pre-populated.
Or please add more information.
Hi Shanmathi,
Yep, that is my requirement. I wanted to have the selected Task Record (from the a!gridField) pre-selected via a Rule Input (parameter) to the Tasks View on the Case Record.I was hoping there would be a good workaround or someway to pass that parameter via a!recordLink and a!urlForRecord.
From everything I can see though it cannot be done excluding through a hacky workaround involving having a Task Record's views mimic the Case Record's views where I could then pass the Task Identifier (recordId)as a parameter given a!recordLink and urlForRecord take an identifier as a parameter.
It looks like the use case is not supported currently.
Yes passing parameters is not supported in the record views. I would suggest to go with your second approach since the client wants to Navigate to record.
The maximum you would be able to drill down inside a record using urlForRecord() is till the views of the record. So, your case is not possible using urlForRecord().
Your second option may introduce maintainability issues. So, like you I am not fond of it too.
I suggest two options here:
1. Create a new interface that mimics the task view of the record that can have rule inputs and call it by passing the inputs using urlforsite()
2. Convince the client that there is no direct way to do it.
Many Thanks Soma & Shanmathi,
I've raised it as a platform limitation with the client. I'll have a look another look at our design.
I think I have a way you could achieve this, although it is admittedly a bit hacky. Assuming you have a relationship between task and case, you could set up your app to send them to a task record instead of a case in this scenario.
For example, you could have your "task record" actually display all of the related case information on the first tab, and the details for the task on the second tab. Then if you had task IDs 1-5 related to case 123, you would have separate URLs for each task but the first tab would all look the same (since they're for the same case).
It might result in some less than desirable UX elsewhere in the app, but it's at least a work around to have each task have its own URL.
Hi Peter,
Haha, yeah this was also the same conclusion i came to above. It is a possibility I'll keep in mind, but we'll also re-look at the design and see if it can be avoided.
zacc0002 said:I have thought of a hacky workaround by having the Task Record mimic the Case Record exposing the same views to the end user. This way I could use the record Identifier of the Task to have it pre-selected, but I am not fond of this approach.