Blog posts by Pawan

Blog posts by Pawan2025-07-21T19:25:10.0000000Zhttps://world.optimizely.com/blogs/pawan/ Optimizely World Optimizely Forms: Forcing New Submission on Every PostBy default, Optimizely Forms uses browser cookies to track submissions and updates the existing submission if the same user submits the form again. While this behavior works well in most scenarios, we had a custom business requirement: for certain forms, each submission needed to be treated as a new entry, regardless of whether it came from the same user or browser session. At the same time, all other forms in the solution were expected to retain the default cookie-based behavior. Initially, this seemed complex, but after inspecting the Optimizely Forms framework, we discovered that the ProgressiveSubmitInfoService class could be leveraged to inject this behavior in a clean and maintainable way, as shown below. <pre class="language-csharp"><code>using EPiServer.Forms.Core.Internal; using EPiServer.Forms.Core.Models.Internal; namespace alloy_example.Customization.Forms; public class ExtendedProgressiveSubmitInfoService : ProgressiveSubmitInfoService { public override ProgressiveSubmitInfo GetProgressiveSubmitInfo(Guid formContentGuid, HttpContext httpContext, string formLanguage) { //var isPathFound = httpContext.Request.Path.StartsWithSegments(RootPath); // e.g. can be checked based on httpContext if (!string.IsNullOrEmpty(httpContext.Request.Form["TestElement"])) { return null; } return base.GetProgressiveSubmitInfo(formContentGuid, httpContext, formLanguage); } }</code></pre> Above code check if Element TestElement is found under httpContext after submission, this it will simply return null and forcing optimizely framework to generate new submissionId for given form submission. As last step, make sure to register in DI container as below. <pre class="language-csharp"><code>using EPiServer.Forms.Core.Internal; services.AddSingleton<ProgressiveSubmitInfoService, ExtendedProgressiveSubmitInfoService>();</code></pre> This overrides the default service and enables custom logic while keeping the framework's core behavior intact. Hope, it helps someone!2025-07-21T19:25:10.0000000Z

Blog post

Disable Report and Dashboard Menu content editorsWe had a requirement where Report and Dashboard menus were needed only for specific roles/users Or Admins — but not for editors. Below is default view for editors where  you can see these menus: <img src="/link/72d9c52674db4b4192af12ece44f346d.aspx" alt="" width="136" height="176" /> But required view is:  <img src="/link/3beeaa0e7076471f97bbd5bf2c7c7098.aspx" alt="" width="126" height="173" /> 1.  To achieve above, we implemented a  custom Interceptor class that wraps another IMenuProvider and overrides the authorization logic as below. <pre class="language-csharp"><code>using EPiServer.Shell.Navigation; namespace alloy_example.Customization.Menus; public class MenuProviderInterceptor : IMenuProvider { private readonly IMenuProvider _menu; public MenuProviderInterceptor(IMenuProvider menu) { _menu = menu; } public IEnumerable<MenuItem> GetMenuItems() { var menuItems = _menu.GetMenuItems().ToList(); menuItems.ForEach(item => { item.AuthorizationPolicy = "episerver:cmsadmin"; }); return menuItems; } }</code></pre>  2. we need to hook this interceptor only for specific providers — like ReportsMenuProvider or DashboardMenuProvider based on requirement. <pre class="language-csharp"><code>services.Intercept<IMenuProvider>(interceptorFactory); private static IMenuProvider interceptorFactory(IServiceProvider provider1, IMenuProvider provider2) { var types = new[] { typeof(ReportsMenuProvider), typeof(DashboardMenuProvider) }; return types.Any(t => t.Equals(provider2.GetType())) ? new MenuProviderInterceptor(provider2) : provider2; }</code></pre> This way, only ReportsMenuProvider and DashboardMenuProvider are affected — all other menus remain untouched. Hope this helps someone!2025-07-20T14:39:07.0000000Z

Blog post

Importing Form Submission Data into Optimizely Forms Using DdsPermanentStorage<div>Recently, we needed to import a large number of records from a third-party system into Optimizely Forms. The data was available in CSV format, and our goal was to insert this data as form submissions within the Optimizely platform. <h4>🔍 The Challenge</h4> During our initial analysis, we discovered that Optimizely Forms does not offer a built-in API to directly insert or update form submissions programmatically. While the method PerformDataSubmit() handles submission automatically through the UI (taking care of cookies and submission IDs), it relies on HttpContext, which we don’t have access to in a scheduled job environment—like in our one-time migration scenario. <img src="/link/a4a3fb3cffc34a0daeb9f9a56c4f4775.aspx" width="629" height="53" /></div> <div> <h4>✅ The Solution: DdsPermanentStorage</h4> After some investigation, we found that the internal class DdsPermanentStorage can be used to directly interact with the Optimizely Forms' data store. This allowed us to insert and update form submissions programmatically without depending on the httpContext. <img src="/link/6116532dea3e48699c54fdff4d2570a9.aspx" width="639" height="244" /> We utilized this class in a scheduled job and were able to import all records successfully. 🔸 Important: To ensure these submissions show up correctly in the Form Submissions view under Edit Mode, you must include the SYSTEMCOLUMN_Language field during creation. <img src="/link/a7307e8e6c504a03a96544a3fb218634.aspx" width="648" height="51" /> <h4>🕒 Handling Custom Submission DateTime</h4> While everything was working well, we noticed that the submission timestamp (Created date) was automatically generated by the system at the time of insertion. However, our source data contained historical submission timestamps, and it was important for reporting and UI display that we preserve these original dates. To solve this, we went one step further and overridden the default behavior to allow setting a custom submission date. We achieved this by extending DdsPermanentStorage as below. <pre class="language-csharp"><code>using EPiServer.Data.Dynamic; using EPiServer.Forms.Core.Data; using EPiServer.Forms.Core.Models; namespace Alloy.Customization.ExtendedDdsPermanentStorage; public class ExtendedDdsPermanentStorage : DdsPermanentStorage { public const string SYSTEMCOLUMN_SubmitTime = "SYSTEMCOLUMN_SubmitTime"; protected override void EnsureFormFieldsExistInPostData (FormIdentity formIden, ref PropertyBag postData, out IDictionary<string, Type> typesBag) { DateTime.TryParse(Convert.ToString(postData[SYSTEMCOLUMN_SubmitTime]), out DateTime submitedTime); base.EnsureFormFieldsExistInPostData(formIden, ref postData, out typesBag); if (submitedTime > DateTime.MinValue) { postData[SYSTEMCOLUMN_SubmitTime] = submitedTime; } } }</code></pre> <h4>🧩 Dependency Injection Setup</h4> Since this custom class may need to be reused in other parts of the solution (or injected), don’t forget to register it in the DI container if you're wrapping it inside a service or using Optimizely’s built-in services. Hope this post helps someone facing the same challenge! </div>2025-07-16T19:35:00.0000000Z

Blog post