I’m deep into a Skuid free trial, sales team that’s piloting loves it and I was ready to pull the trigger on upgrade and full team rollout, then ran into one showstopper issue that feels simple to solve but I’m at wit’s end after trying for 2 long days to debug…

Background and Use Case:

• We have 2 custom fields on the Contact object: Prospecting Stage (picklist) and Follow-Up Date (date). Many other custom fields, but irrelevant to current issue.


• We’ve been using standard SFDC Workflow Rules for over a year to enforce dependencies and auto-update these field values. For example, a Contact in early prospecting stages should have a short interval–2 days–before following up; moving a prospect to stage 4 should set FU date to 5 days hence; etc.


• 
  These workflow rules and field updates worked flawlessly before installing Skuid, and continue to work flawlessly for non-Skuid users.


• I created 3 Skuid pages which all have Contact models. The Contact models are used in a variety of components on each page (field editors, tables, popups, drawers).


• By popular request, we decided to eliminate enforcing the field dependencies and let reps pick their own follow-up dates, so disabled the workflow rule that yoked a preset interval for follow-up date to the selected prospecting stage.


• That’s when the fun began…read on (pretty please!)

Issue and How to Reproduce:

• 
  

  On ContactTab page (my Skuid override for Contact list page) or via Contact Detail page (still a standard SFDC record detail page), update field values in the Prospecting Stage (custom picklist) and Follow-Up Date (custom date).

  
  


• 
  

  Save changes. All looks good, values are updated successfully…BUT…

  
  


• 
  

  Wait a few minutes, reload page (the delay before problem occurs is what has me thinking issue is Skuid interaction w/ workflows).

  
  


• 
  

  Prospecting Stage value reverts to first value in the picklist.

  
  


• 
  

  Follow-up Date value is also changed to correspond to default interval for this stage as per workflow rule. Though I thought it was deactivated. But we have a sh**load of workflow rules that touch the Contact object, so can’t guarantee they are ALL deactivated (I’m running in production, have to tread lightly and iteratively).
  What I’ve Already Tried:

  
  


• 
  

  Deactivating workflow rules that modify these field values (with caveat above).

  
  


• 
  

  Ensuring all Contact fields leveraged by workflow rules are included in the Contact models on all pages.

  
  


• 
  

  Verified that the non-Skuid users are NOT having the same issue when they update these fields on standard SFDC pages. Their changes stick.
  One Weird Thing I’ve Noticed (possibly unrelated but throwing everything + kitchen sink in my plea for help)

  
  


• 
  

  I had some table filters in an early draft of the ContactTab page.

  
  


• 
  

  I set model-level conditions (filterable, off by default) on filters for the fields in question.

  
  


• 
  

  I deleted the draft filters and replaced with others, BUT

  
  


• 
  

  The filter conditions are still present in model, greyed out, with message that they can’t be removed except by filter that created them. Which is hard, since the filters are deleted now
  
  Current state of Contact model conditions on the ContactTab:

  
  

CAN ANYONE HELP?!? I’m out of bandwidth starting Monday, if I can’t solve this weekend we’ll have to shelve the trial and revert the pilot team to painful pre-Skuid business as usual. Which would make them (and me) very sad…

Thanks in advance to any brave souls willing to venture into this morass…

Cheers,

~Daniel