Field value changes in Skuid get overridden (by workflows, perhaps?)

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 :open_mouth:
    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

Daniel,

Unless you have JavaScript or Actions that modify your models, Skuid is just performing a SOQL query whenever the page loads.

There is a lot one can do to debug this issue, for example,

  • Open Chrome developer tools and inspect your models (data and conditions)
  • Inspect the generated SOQL 
  • Use Developer Console and execute the Skuid generated SOQL, review the results
Note, you really should be working in a Sandbox and not in your Production Org.

As far as the filters go, have your tried editing the XML and removing them?

Regards,
Irvin

Thanks Irvin. Followed your tip and removed the filters in the XML.  As for developer tools, I know how to get in and take a cursory look, but am not a developer, let alone an Apex guy, so inspecting SOQL is beyond my ken.

At this point, Skuid is down for me anyway–hope it’s a site outage or downtime for upgrade. Can’t even get to Skuid Central or the Pages tab, seeing timeouts. Crossing my fingers simply deleting a few lines of XML on one page isn’t now causing larger problems!

Cool, you’ve got past one issue.  Weird, probably should be investigated, later, but you are past it.

Note: you should always make a Version of your page before editing the XML. 

What part of Skuid is “down”?  I am in the community right now since I am typing this response :slight_smile: I am able to hit Central and Pages tabs.

Do you have a Sandbox?  Without jumping in to the developer deep end, in the Sandbox you could disable all workflows and then working you way back from there, activate one at a time.


Community is fine (I’m here), but within SFDC I can’t get to any Skuid pages. Double-checked pkg install expiry, I’m good there.  Not sure what else to do…

No sandbox, but re: disabling workflows I’m wondering why non-Skuid users are not having any issues with mysterious reversion of Contact field values? And why Skuid users who go to the non-overridden Contact Detail page to make edits experience the reversion of values.

I’m just getting a timeout when I try to navigate to the Pages tab in SFDC (or any other Skuid page):

Daniel.   Would you mind giving us login rights to your org so we can take a look at what is going on?   Here is how: 

1. Use this tutorial to give us login rights: http://help.skuidify.com/m/getting-started/l/182412-getting-help-how-to-grant-skuid-login-rights-to-…

2. Then send an email to support@skuidify.com  with the following information: 

- Your org Id 

- The name of the page where the problem is happening 

- The steps required to reproduce the problem.  


We’ll see what’s going on…