Recognizing USERSETTINGS(my field name) in report template expressions

I’m having no luck using USERSETTINGS() values in report expressions or even as part of my data table slice. They just seem to be ignored. So I’m wondering if that is expected behavior. Thanks.

Seems to be all working for me. Do you have things setup as below?

1 Like

Thanks Marc for your prompt response, and my apologies for the delay in get backing to you. I thought I could do a better job fleshing out the core issue (slice formula not being reflected), so here goes:

My user settings are used for my slice condition, are set at state = Ohio and city = Akron, and display perfectly in simulation on the development laptop. But in report results the full table is being reported even though my report uses that same slice.

Note that:

– All usersettings have Show set on
– Report uses entire table with no “if this is true” condition/s
– The email body is set as follows (Tool4ForAppsheet is the main table which uses _RowNumber as the key, and vCityState is a virtual column and Block a long text column - both of which report properly except for the filtering issue):

<Start:Tool4ForAppsheet[_RowNumber]>
<<[vCityState]>><<[Block]>>
<>

(The end snippet does not display in the post, but is correct in the app).

Your help is greatly appreciated.

You’re telling the report to display the entire table right here, not the slice. Change “Tool4ForAppsheet” to the slice name.

Yes, thank you Marc - that corrected the entire file being reported, but the filtering reflects my initial usersettings (under autocompute) for the variables and not the settings I actually set/synced and which are correctly being used in the app view itself. If I remove all such initial settings and then actually set/sync my settings in the app, the entire file is once again being reported. If I had hair I’d be pulling away! Marc, what am I doing wrong?

1 Like

UserSettings are not present for Reports.

UserSettings are only stored on the client. The client includes the UserSettings when it calls the server while doing a Sync (Read), Add, Update, or Delete. As a result, the UserSettings are available on the server while the server is doing the Sync (Read), Add, Update, or Delete. The UserSetings are also available for the workflow rules triggered by the Add, Update, or Delete.

A Report is triggered when the schedule service determines that it is time to invoke the Report. The scheduled service calls the server to invoke the Report. The schedule service has no access to the UserSettings so it does not include UserSettings when it calls the service. Likewise, the service has no access to the UserSettings. Therefore when a Report runs the UserSettings are empty.

4 Likes

Thank you Phil - that’s clarifying but disappointing. The workaround I found to that is to put the desired settings into “initial value”. But I don’t want to start doing that if that capability will be removed - do you think that’s likely? Also, a question if I might: If I use virtual columns to store my desired values, can my reports see those?

Oh…right, that makes sense.

To rephrase what Phil said, Reports are an app-wide action, and not user-specific. Applying a user-setting to a report wouldn’t make any sense.

I don’t really have much suggestion for you, without knowing more details about what you’re trying to accomplish.

The initial value of what?

If your virtual column is referencing USERSETTINGS(), I believe you’ll run into the same problem, as the virtual column will be re-calculated upon the running of the report, in the context of a report, and thus not have any user settings to access.

2 Likes

Marc, thanks very much for your help and the time you spent with me on this. Have a nice weekend.

1 Like

What if you have a Users table in your data source where each user would have the same data you were storing in UserSettings. Then it would always be available.

1 Like

Lucinda, thanks VERY much for what looks like a great solution. The problem functionality was related to my marketing of the app and not the app’s user experience. So I decided to abort that approach and resort to a tried and true marketing video. But I will come back to your solution in the future when I add some actual reports to the app’s real purpose. Once again, I really appreciate your jumping in on this.

1 Like