A good example of a situation where a "survey mode" would be awesome and super helpful (i.e., a "force anonymous" option in the publishing settings). 

Originally, I thought about just having a 3rd "anonymous" option that behaved like public but never stored/tracked user info, however, it might work better as a supplemental setting that can apply to either public or restricted.

I can think of several scenarios in which it would be nice to restrict access without tracking users, like an employee survey that should only be accessible to specific users but doesn't track their info in the instance details.

Basically, allowing access and user tracking to be set separately so we can force any form, whether public or restricted, to be anonymous.

On a side note, another thing to consider would be IP tracking. Even when a form is submitted "anonymously" Forms still tracks the submitter's IP address, which could, in some cases, be used to identify submitters.

Noted, I will see if we have any existing research into the topic. Cloud and self-hosted should behave the same and perhaps adding this as an option would let us merge the behaviors 

I agree, it wouldn't be the best user experience to be forced to log out, although for our company I'm thinking it might be beneficial.

To add some context: we currently have two Forms portals, one running 10.4 and one running 11.0. The 10.4 portal has public access, which is the majority of our forms (some ~95%). This works great as when we do need to gather customer information using external forms we can do that easily. The 11.0 portal is strictly for HR purposes. This portal is relatively new, around 6 months old at the time of writing this, without public access.

This wasn't scoped too well (in my opinion, at least) as it was never brought up that anonymous internal surveys or feedback would be developed using Laserfiche. As they've gotten comfortable with the idea of using LF and understanding the restrictions, it'd be a streamline process if the HR portal would allow for anonymous submissions. We currently have one major process set up in that portal which uses an SQL query to delete all data out of a survey response. This works really well, although is managed externally by our reseller.

We could just go to them and ask for that process to be implemented each time, however it's quite expensive. That's the reason I was hoping to do this through some sort of script. If not then we'd need to do a cost analysis of if it's better to purchase the external license or to pay each time to get a form process set up to remove data.

Also to keep in mind that not every employee here is very 'tech literate' and would struggle with manually logging out and back in if prompted to. What Jason mentioned above about an "anonymous" setting would be incredibly helpful in these situations, too. Was hoping that'd come to 12 or an update for 10.4 and newer would come along.

Just realised I confused myself between the two portals. We're wanting to check if it's possible in a public portal to force log out someone before determining if we want to spend the money to upgrade our 11.0 portal to have access or if it's better to just pay each time to get our reseller to use SQL queries.

Sorry about that; lost track of my own inquiry haha

Is there a reason you're deleting data from the SQL database directly? I can't remember when the process-specific policies were added, but you can override global data retention policies and delete the instance data automatically.

Could that be used instantly after the form has finished? The way the current survey we have set up in there works is that it has a time period it remains active before being terminated. It's sent out from a request form to employees to fill out, and to ensure total anonymity and to comply with out data policies, it's just deleted straight out of the SQL server. It was the method recommended by our reseller so that it's impossible to trace a response back to any individual. 

It is not instant; in Forms admin you set a start/end time for scheduled internal data maintenance. When this runs, it finds completed instances and deletes eligible data according to the global or process-specific policies.

Data Maintenance Policies | Laserfiche Forms

Although I understand wanting data removed as soon as possible, one of the reasons direct changes to databases are discouraged is they are outside the context of the application and could potentially conflict with these types of internal processes, especially as functionality evolves with new versions.

Yeah, it didn't sound like a best practice when it was first described, although in order to satisfy the guarantee that no-one sees the information in the survey responses the SQL query was the only way. As everyone was already used to seeing information in forms they assumed it would be the same and they could see their responses. The survey process is for manager and senior manager performance amongst their peers and colleagues.

I also had a go at incorporating the '.../Forms/account/logoff' URL you mentioned in another thread, which seems to hit a roadblock as it can't redirect back to the original form it came from once the user is signed out.

<!-- Logout button -->

<a href="https://{server}/Forms/account/logoff" onclick="setTimeout(function() { window.location.href = 'initial form URL'; }, 5000); return true;">Click here to logout</a>

Reckon there's a way to just do it like that? Trying to avoid a standard HTML prompt or teaching users how to logout manually and navigate back to a form

I kind of threw this together just to see if it would work, and this code would only work in the classic designer, so your mileage may vary but I tried using an iframe in a custom html element.

• read-only field, with class "username" and default of current user
• custom html element with a clickable link to be used with javascript
• custom html with an iframe
• a section to contain the actual form content

In the field rules:

• The iframe is set to always hidden so it is only visible in the designer
• The logout url and form section are shown/hidden based on the content of the username field (this will vary depending on whether you use the current username, name, email, etc.)

In the JavaScript:

• Check the value of the username field and, if not anonymous, add click event handler to load the logout url (again, the exact value you want to check for depends on what you use for the default)
  • Replace the logout url text with a message
  • Add load event handler to iframe that refreshes the page
  • Open the logout url in the iframe

Fields

Class on "Completing form as" field

Link html

<p><a id="logout" href="javascript:void(0)">Click here to log out</a></p>

iframe html

<iframe id="logoutframe" src="about:blank"></iframe>

Field Rules

JavaScript

$(document).ready(function () {
  // window check is to prevent running in designer and other frames
  // affects task windows but anonymous users can't open tasks
  if (window.self === window.top && $('.username input').val() != 'Anonymous User') {
    // hide submit button
    $('.Submit').hide();
    
    // add event handler to link
    $('#logout').on('click', function () {
      // set message
      $(this).replaceWith('logging out...');
      
      // set callback for iframe loading
      $('#logoutframe').on('load', function () {
        location.reload();
      });
      // open logout url in frame (replace with your value)
      $('#logoutframe').prop('src', logoutUrl);
    });
  }
});

Results