Users are losing filters when they go back to the reports.

Can you clarify what you mean by losing filters when going back to reports?

Hi davidwi can you please elaborate your exact requirement.
if you want apply filters while creating reports refer the below link.
it will guide you to apply filters.
forum.appian.com/.../SAIL_Recipes.html

AFAIK there is nothing OOTB to do that. I was also thinking about this for some time now. My idea is this: For saving filter settings in a custom report or tasks report you could save the filter config to DB using the "Start Process Writer" plugin and load it initially when the user opens the report. For record lists this will not work.

Thanks Stefan, that's where my thinking was going as well but seems like a massive workaround at the moment.

So the use case is a user filters their reports to see the work, clicks a link to go to the task / record and then goes back to the report. When the user goes back to the report the filter settings are lost and they need to reapply them.

They are finding this really inefficient.

You can save the filter setting as the users alters it. The plugin allows you to start a process in background in a saveInto of a SAIL component. So your users do just have to interact with the filter controls. A "Reset Filter" button/link might be a good idea.

You could also move the task report to an action and persist their filters within a process - but that's not particularly elegant either..

@davidwi As said by @stefanh Start Process Writer can serve these kind of purposes and at the same time it leads to massive implementations at time as thought by you because we used Start Process Writer in some areas in the project and yes, they require quiet a lot of work(depending on the usecase) and unfortunately this work will only fit the corresponding usecase most of the times. But for the time-being, Start Process Writer is the only plugin that can allow us to plan some work around by triggering a process from the SAIL interfaces.

As mentioned above, we are using the Start Process Writer plugin to achieve this functionality, with the plugin installed it is less work than it appears. One DB table holds [report], [empId], [option], [setting]. Each report will call a query rule on load() based on the loggedinuser() and report (text value) to retrieve a set of stored defaults (option & setting) for the report being viewed. Any found defaults are then used in setting load values for all fields, and 2 links on the report are used with Start Process Writer for Set Defaults and Clear Defaults. Set sends current filter values to a process model as inputs, stores off to the DB - Clear simply empties the DB for the current loggedinuser() and report.

This code also contains a 'COLUMNS' parameter, used for a checkbox list selection to allow users to add/remove columns from the report, which is also saved with default filters.

=load(
local!report: "WRS_all",
local!setDefaultModelId: cons!SET_REPORT_DEFAULT_MODEL_ID,
local!loggedInId: rule!getEmployeeID(loggedinuser()), /* function grabs from user record */
local!defaultFilters: rule!BPM_qrGetReportDefaults(local!loggedInId,local!report),
local!defaultColumns: rule!BPM_getDefaultFilter(local!defaultFilters,"COLUMNS"),
local!processWrite: bind(get: {}, set: startprocesswrite(processModelId: local!setDefaultModelId, processParameters:_)),
local!filterStatus: rule!BPM_getDefaultFilter(local!defaultFilters,"status"),
local!filterStage: rule!BPM_getDefaultFilter(local!defaultFilters,"stage"),
.
.
a!dropdownField(
label: "Status",
labelPosition: "ADJACENT",
placeHolderLabel: "All",
choiceLabels: {"Active","Completed","Cancelled"},
choiceValues: {"Active","Completed","Cancelled"},
value: local!filterStatus,
saveInto: local!filterStatus
)
.
.
a!richTextDisplayField(
value: {
a!richTextItem(
text: "Set Defaults",
link:
a!dynamicLink(
value: {
report: local!report,
empId: local!loggedInId,
operator: "set",
option: {"stage","status"},
setting: {local!filterStage,local!filterStatus},
COLUMNS: local!columnSelection
},
saveInto: {
local!processWrite
}
)
),
" | ",
a!richTextItem(
text: "Clear Defaults",
link:
a!dynamicLink(
value: {
report: local!report,
empId: local!loggedInId,
operator: "clear",
option: {},
setting: {}
},
saveInto: {
local!processWrite,
a!save(local!filterStatus,null),
a!save(local!filterStage,null)
}
)
)
}
)
.
.
)


rule!BPM_getDefaultFilter(defaultFilters,option): /* defaultFilters = Any Type, option = Text */

with(
local!options: apply(fn!tostring,ri!defaultFilters.option),
local!settings: apply(fn!tostring,ri!defaultFilters.setting),

if(ri!option="COLUMNS",
index(local!settings,wherecontains("COLUMNS",local!options),null),
displayValue(ri!option,local!options,local!settings,null)
)
)

Thanks a lot for the details :-)

Just chiming in to add my support for csteward's version of this implementation - specifically, only start the process writer to save default values when a button or link is clicked, instead of every time a user changes a filter.

Additionally I strongly suggest for anyone thinking of using a tempo record as a "Record Power Search" (which users seem to like), make the record links open in a new tab by using a!safeLink instead of a!recordLink which requires manual user intervention to open in a new tab. This cuts down significantly in the rate at which users need to jump back and forth between record entries and the report, and re-do whatever filtering they like.