Limiting Overview or Inbox records to the user to submitted them?
You can set your service settings to only show features to users who create them:
This would effectively limit the Inbox / Overview in the way you want. If you need to see all the data in other contexts, you can create different views of the feature service with different settings.
Alternavite solution is to use a WHERE clause.
Go to the Options page, and enter your WHERE clause. The Learn more button gives you instructions on limiting the inbox to a person.
Short answers:
Does that work with editor tracking fields not present in the form?
Yes.
does ${username} actually get the logged in user's name
Yes.
Longer answer, because it may be of interest.
The second half of this query is easy. ${username} will always be the username of the person signed into the app. If someone isn't signed in, this is blank.
The first half is straight-forward, but potentially complicated. It is a field you specify in S123. To get data into this field, you have a few options:
- Use the method built into S123 to grab the username (Note: name/label can be anything you want). The setup below will contain the user's username if they are logged in, or be blank if they are not.
- Have the user enter their username manually (e.g., a dropdown)
- Use both options 1 and 2.
I have personally settled on using Option 3 going forward.
Reason: Users go out into the field and may not be logged in when the form first opens, meaning their username is blank. This has resulted in "missing" data, and me manually filling in the missing username in Portal.
Explanation: If the user is signed in, then the field gn_assessor (which is required) will contain their username. If they are not signed in, gn_assessor will be empty--if they try to submit the form, they will be prompted to enter their username here by selecting from a dropdown.
Set-up:
| Line in Excel | name | visible | Purpose |
| 2 | header_username | no | A special field built into S123. This will pull the username of the person signed in. |
| 41 | gn_assessor | yes | An external select I set up containing all staff in the company. Has a calculate to pull the value of ${username_email1} |
| 42 | username_email1 | no | A containor for ${header_username}. I theoretically could just pull directly from ${header_username}, but this made writing the calculates easier. |
| 43 | username_email2 | no | Pulls the email from my external CSV based on the selection made in ${gn_assessor} |
| 44 | username_email_h | no | I use coalesce to ensure this field always has a "username" (In my case, an email). If ${username_email1} is blank, coalesce() = ${username_email2}. If ${username_email1} is not blank, coalesce() = ${username_email1} |
| 45-48 | <varies> | no | Just there to complete the example. I am pulling user information from my external CSV based on the email in ${gn_assessor} |
And this is generally how the external CSV is set-up:
