SanfordWhiteman

Already simple to do. Have a program token with the date (you may already have this). Put a tiny JavaScript snippet that redirects if the date has expired.

Yes. An Apex trigger that persists (minimal) metadata about versions/updates to child records.

Yeah Josh, you'd need to have a trigger. Which kind of makes the formula redundant (since the trigger could probably replicate the formula into a static field). Still it could be good for distributing responsibilities (like an admin-level person maintains the formula and a system-level developer ma...

I didn't necessarily mean a literal field of the Roll-Up Summary type but a triggered field with an equivalent function. But RUS fields do fire triggers, so in fact they can update SystemModstamp.

Looks simple. Use their client API (walkme_event) to hook user activities and fire Munchkin clickLink events. What's the problem?

Valerie, if you have an Apex developer a lot of times this can be done via a rollup field on the Contact object. Details stay on the custom/child object, but the master/parent maintains knowledge of changes to children.

Way too much duplication there and it won't scale. Do it like this: MktoForms2 :: Indie Checkboxes to Virtual Radio Set Advanced This version uses an array of collections. [ 'input[name=myName], #myId', '#myFieldset input[type=checkbox]', '#anotherCbx1, #anotherCbx2...

Well, I wouldn't say you cannot, but you should not. It's better to work on restyling the form than actually changing the form DOM. Though I've been known to do the latter if necesssary. Anyway, changing out the INPUT[type=submit] for an A would never be advisable. A BUTTON is more semantically...

FYI there's no need for the jQuery(document).ready() wrapper here. By definition, the form is already ready in the DOM when MktoForms2.whenReady() fires.

It's a CSS selector list, so if those are IDs: #id1, #id2, #id3You can even make more complex groups, like ,myName, #myId, #myFieldset input[type=checkbox]