Два варианта. Или рисуешь триггер на after update для таблицы incident_base, в триггерной функции в новую таблицу пхаешь нужные данные об изменении - но тогда ты не увидишь из интерфейса историю - способ только для контроля со стороны DBA. А хочешь увидеть (к примеру, на новой вкладочке формы) - пишешь плагин с тем же самым (данные об изменении статуса во вновь созданный объект пхаешь) и цепляешь его на событие on change.

Никаких камней нету. Надо иметь SDK, в состав которого входит документация, библиотеки и админская часть, с помощью которой подключаются готовые dll-ки с плагинами к CRM.
Внимательно читайте документацию !
В соседнем топике я приводил пример плагина.

Еще вариант - смешанный из двух.
1) Создаешь через стандартный интерфейс CRM объект для хранения истории incident_history, в нем, естественно, создаешь связь M-1 с incident
2) Рисуешь в базе триггер на after update для таблицы incidet_base, в триггерной функции будет всего 1 оператор: insert into incident_history_base ...

Достоинства:
1) не надо заморачиваться с SDK
2) производительность выше
Недостатки:
1) Надо задокументировать везде, где можно, в первую очередь - в базе знаний CRM, дабы при переносе (апгрейде и т.д.) фича не потерялась, и чтоб следующие админы-разработчики не ругались
2) а больше и нету, вроде