Всем привет.
Кастомеры попросили создать фукнционал, позволяющий им проводить опросы среди сотрудников. Содержание вопросов неизвестно заранее, то есть они сами их определяют по текущей потребности.
Мой варинат для простого приложение для опросов.
(1) Кастомный объект "Опрос" с перечнем стандартных вопросов как "Пол" и N-ное количество условно "спаренных" полей, в которых одно поле для вопроса, второе для ответа. "спаренные" поля создаются, к примеры по 20 шт для текстого значения в ответе, по 10 шт для численных значений.
(2) ВФ страница "Создай опрос". На этой странице автор опроса задает тему, вводит список емайлов участников, и создает "вопросы": выбирает какие использовать из стандартных, добавляет кастомные вопросы с нужным типом ответа. Кликает на "Создать" и контроллер, к примеру создает 20 новых записей с темой, кастомными вопросами, участником и каждому из них отправляет Емайл с линком на вторую ВФ страницу с айди "его" записи как параметр.
(3) При клике на этот линк, участник попадает на вторую ВФ страницу, которая проверяет какие "спаренные" поля имеют значение в полях для кастомного вопроса и рендерят только эти поля, плюс др какие необходимо.
При клике "Отправить", запись сохраняется, и бул поле "Заполнено" оставливает WFA которое ежедневно отправляется напоминаение об опросе и не дает контроллеру второй страницы снова "открыть" запись участнику.
(4) ну и главное для опроса - это репорты. Их кастомеры должны пилить самостоятельно исходя из того, что у них там в их опросе.
Я так себе это представляю. Может вас эта тема заинтересовала и\или есть какие-то идеи\опыт по теме? Или проще использовать какие-то готовые решение (но в пределах СФ орга)?
Вроде архитектурные вопросы мы еще не обсуждали, а это большая тема...
ну как я вижу:
1. Мастер объект - Опрос(Название/Описание)
2. Объект (мастер лукап на опрос) - Вопрос(Название)
3. Объект (мастер лукап на Вопрос) - Ответ(Название/Лукап на юзера)
Это только по объектам.
ух, такая Ёлочка похитрее будет.
дает больше гибкости, но надо ее хорошенько в уме представить, чтоб понять какие ограничения мы имеем
Добавлено:
первые два объекта позволяют нам не дублировать инфу (нормализация БД)
второй объект позволяет делать не ограниченное кол-во вопросов.
и вся "движуха" идет на объекте третьего уровня.
остается только правильно организовать первую и вторую ВФ страницы.
плюс быть уверенными, что с такой схемой они смогут в отчетах получить все что им нужно
Задача вроде типовая. Нельзя просто купить готовое приложение на AppExchange? Сорри за оффтоп.
вполне возможно, что можно и купить готовое решение.
но здесь же "клуб юных архитекторов", т.е. пробуем получить решение самостоятельно, и возможно даже и попробуем воплотить его, если будет дана команда.
Не, я все понимаю 
это правда интересно. Я просто посмотрел на задачу с финансовой стороны 
может купить дещевле. Продайте эту мысль начальству - получите бонус
По делу, предложенная схема неплоха, единственно что тут надо подумать отношения master-detail или lookup. Потому как если все master detail то непонятно как не показавать пользователям ответы друг друга. Другой интересный вопрос: возможные типы ответов (text, checkbox, multichoice) и как их хранить в объекте ответа. Если в виду отдельных полей - то нужно менять объект при добавлении типа вопроса (а их точно будут добавлять), если в каком-то сериализованном виде - отваливаются стандартные репорты и надо собирать вручную.
Да, тем и интересна задача, что она типовая. размышлизмы об ней могут еще где-нибудь пригодится.
Многократно важнее - это репорты, так как они создают смысл Опроса. и в других темах адекватный Репортинг важен, но здесь он вообще самое главное. И конечно нужно стараться обойтесь стандартными Репортами. А как для них лучше Мастер-Дитэйл или обычная связь - я не знаю.
пока представляю по простому: фиксированное число возможных типов в пиклисте на записе Вопрос и все эти типы в виде разных полей на Ответе. Выбирешь тип в Вопросе, и ВФ страницы ренедерят из Ответа только соответвующее по типу поле.
Кстати его можно просто поставить и подсмотреть структуру базы 
Вы все правильно сказали.
посмотрел, как сделано у других.
четыре основных объекта:
survey -> questions (child)
invitation -> answers (child)
и лук-апные связи между ними.
Вывод такой: если хочешь определится с архитектурой нового приложения, то:
(1) хорошенько все обдумай сам (это самое главное, даже если твое решение не оптимально);
(2) спроси людей на форуме (сколько раз убеждался насколько это полезно, даже если тебе кажется что ты знаешь верный ответ);
(3) посмотри как это работает у других и еще раз все обдумай.
спасибо
Ждем пакет на AppExcange
продолжение темы "Приложение для опросов".
увидел, что коллеги работают с аналогичной, но более сложной и интересной задачей.
есть опросники с перечнем вопросов, но у них логика опроса может "ветвиться"! то есть в зависимости от ответа могут быть разными последующие вопросы (группа из них).
я сразу сказал, а почему не Visual Flow? - он как раз для этого и существует.
отвечают, что эти Опросники время от времени меняются, да и много их, и поэтому сами пользователи должны будут составлять их и очерчивать логику. А Visual Flow для них слишком сложен. Поэтому делают кастомное приложение с более простым инетерфейсом.
у них есть ВФ страница, где пользователь создает Опрос - выбирая последовательность Вопросов. т.е. каждый Шаг опроса (это спец сущность) имеет поле указывающее на текущий вопрос, предыдущий вопрос и варианты следующих вопросов в зависимоти от ответа. Вроде все выгладит логично, но не знаю как будут проходить эти "ветвления" логики в реальности; как это визуализировать для кастомера, чтобы он понял как создаваемая им логика Опроса выглядит в конце концов.
Много вопросов. Но задача понравилась, интересно.
