On #1: I have been basically pursuing #1 by creating a custom web tab and then pointing it to the Skuid URL from the “Preview” button on the Skuid page builder view. That’s pretty easy to do for tab pages and seems to work. Is that the correct way to do it? I could not figure out how to have it do a look up and then pull the required detail page. # 2. doesn’t work for us because profiles are too rigid a SF concept. At my company, we need different views depending on what kind of work we’re doing in our work-flow. For example, we either enter or update/build out Contact and Company data in the research stage of our process. We need access to certain fields such as email and contact verification-- once verified, we really don’t need to see those fields anymore. Next we conduct outreach – and need access to calling, emailing, and social networking fields. Then we gather additional info from the people we’re contacting. . .and there are relevant fields relating to that activity. Then there’s a business development stage. Since most people in my organization wear multiple hats (profiles), locking a user into a single profile that then maps to record types/record layouts doesn’t work for us. However, as far as I can tell, the tabs in Squid are the solution. They enable us to pull different mixes of fields into different layouts for the different stages of our workflow. That is awesome (!) Of the 3 options, #3 seems best, because we plan on using tabs sets a lot. The SF view could be tucked away in a tab. Your #3 seems a variation of #1. It would be great if you could detail how to do #1 and #3 in your tutorials for the different kinds of Skuid pages.
