236 results found

1. Support Newer .NET WebApplicationBuilder

   I would like to use the newer WebApplicationBuilder / IHostApplicationBuilder introduced in .NET 6 to initialize the CMS instead of the .NET Core 3 method of using IHostBuilder, because .NET Aspire does not support IHostBuilder. The ConfigureCmsDefaults method does not support WebApplicationBuilder, and even though the following code will compile, the CMS is not usable:

   var builder = WebApplication.CreateBuilder(args);
   builder.Host.ConfigureCmsDefaults();

   4 votes

   Vote Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   New  ·  0 comments  ·  Implementation  ·  Delete…  ·  Admin →
   How important is this to you?

   Nice to have You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Submit Rating

2. Add .NET Counter publication to App Insights on Startup

   There are a whole suite of .NET counters available to use to publish to App Insights. This is a low-lift modification that enables us to gain many insights, directly inside of App Insights Metrics, we can utilize to diagnose issues on customers.

   This enables us to do performance investigations that otherwise require manual intervention (such as downloading .ETL files and opening them in PerfView or capturing dump files and analyzing them).

   We can skip these manual steps and jump write to "close to root causes" by publishing this information. There is little cost and no significant performance degradation associated with publishing this information because Microsoft has designed these metrics to be high performance to collect.

   Having this information available to us enables us to build further features such as success metrics into dashboards for partners to gauge the success of their implementation by taking this information and other information we've build into the Dashboard and surfacing it up in a useful way to the user base.

   There are a whole suite of .NET counters available to use to publish to App Insights. This is a low-lift modification that enables us to gain many insights, directly inside of App Insights Metrics, we can utilize to diagnose issues on customers.

   This enables us to do performance investigations that otherwise require manual intervention (such as downloading .ETL files and opening them in PerfView or capturing dump files and analyzing them).

   We can skip these manual steps and jump write to "close to root causes" by publishing this information. There is little cost and no significant performance degradation associated with… more

   • 

   2 votes

   Vote Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   Gathering Feedback  ·  0 comments  ·  DXP, Hosting & Infrastructure  ·  Delete…  ·  Admin →
   How important is this to you?

   Nice to have You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Submit Rating

3. HSTS on the root domain

   We are experiencing some redirection issues we have no control over as they are done in the root domain.

   http://oldsite.com redirects to https://www.oldsite.com then finally to https://www.newsite.com

   The redirection should be as follows:

   http://oldsite.com -> https://oldsite.com -> https://www.newsite.com

   Please update Optimzely’s configuration to do these redirects properly

   30 votes

   Vote Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   Gathering Feedback  ·  4 comments  ·  DXP, Hosting & Infrastructure  ·  Delete…  ·  Admin →
   How important is this to you?

   Nice to have You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Submit Rating

4. IQI Report - App Insights as the Source of Truth

   There are multiple similar functions happening that are similar within Optimizely. They all need to be utilizing the same data a the singular source of truth. They are:

   1. Incident Management, primary data is App Insights.

   2. Deep diagnostics done by Problem Management, primary data is App Insights

   3. App Insights Dashboard

   4. IQI Health Check reporting, primary information (aside from pingdom's availability info which for legal reasons) is Cloud Flare for health information.

   The inconsistency of source data causes issues because we cannot make a consistent presentation of the information when the source being utilized is entirely different.

   It also adds possibility of deviation of information because CloudFlare adds network hops and the possibility of transforming HTTP Status Codes, etc. So, the information can be altered in an unproductive way.

   If we want to add CloudFlare reporting, we should add targeted CloudFlare specific reports to the IQI report. These should identify discrepancies within the CloudFlare environment that are frequently done as differentials between App Insights and CloudFlare - such as delays in response from CloudFlare that are not caused by backend systems.

   There are multiple similar functions happening that are similar within Optimizely. They all need to be utilizing the same data a the singular source of truth. They are:

   1. Incident Management, primary data is App Insights.

   2. Deep diagnostics done by Problem Management, primary data is App Insights

   3. App Insights Dashboard

   4. IQI Health Check reporting, primary information (aside from pingdom's availability info which for legal reasons) is Cloud Flare for health information.

   The inconsistency of source data causes issues because we cannot make a consistent presentation of the information when the source being utilized is entirely different.

   It also adds possibility of… more

   1 vote

   Vote Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   Gathering Feedback  ·  1 comment  ·  DXP, Hosting & Infrastructure  ·  Delete…  ·  Admin →
   How important is this to you?

   Nice to have You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Submit Rating

5. CMS Page Previews

   When previewing unpublished pages in the CMS, nested blocks (such as unpublished child blocks within a parent block) do not display correctly at the page level, making it impossible for publishers to see the full layout and content as it will appear when published. This limitation forces the team to rely on the Advanced Review plugin, which does show all nested unpublished content but introduces extra steps and performance issues.

   12 votes

   Vote Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   Gathering Feedback  ·  2 comments  ·  Editing (Content)  ·  Delete…  ·  Admin →
   How important is this to you?

   Nice to have You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Submit Rating

6. Expose categories in Graph

   Categories are part of CMS 13 but they're not supported by Graph yet. We use them for filtering content.

   1 vote

   Vote Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   1 comment  ·  Graph  ·  Delete…  ·  Admin →
   How important is this to you?

   Nice to have You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Submit Rating
   Gathering Feedback  ·  AdminCiara Bergin (Principal Product Manager, Optimizely) responded

   We’re currently gathering additional feedback on this idea. If you have any more context, examples, or specific use cases, please share them - it really helps us understand how this would best support your workflow. Thanks for contributing to the conversation!

7. Editor Content Health Dashboard : A personalized, self-service governance view for every content editor in the CMS

   As a content editor, I want to see a personalized dashboard when I log in to the CMS that shows me only the content I own that needs attention, so that I can find and fix issues myself, without waiting for someone else to tell me about them.

   This dashboard replaces the generic default view in the CMS for all content editors. It does not replace any existing admin tools or reports. The intent is to move content governance from a reactive, admin-led activity into a proactive, editor-led habit. The dashboard is the trigger for that behavioural shift. This is a single story that covers the concept and requirements. If the team needs to break it into smaller stories per dashboard section for sprint planning, that is a valid approach, but the sections should be built as one coherent interface, not as separate standalone tools.

   The problem we are solving
   Today, the CMS shows every editor the same generic dashboard. It is not personalized, it does not show issues specific to that editor's content, and it gives no signal about whether the content they own is healthy or broken. The result is that content problems, broken links, outdated pages, unused media, unpublished drafts, go unnoticed for months or even years, until an admin, a customer complaint, or a site audit surfaces them. By that point the damage is already done.
   With over 100 editors across our sites, we cannot rely on a central team or a CMS administrator to track and chase every editor about their content. That model does not scale. Governance needs to become a personal responsibility and for that to happen, editors need to be able to see their own issues at a glance the moment they log in.

   Who this is for
   This dashboard is for every person who creates, edits, or publishes content in the CMS. That includes marketing editors, regional content managers, product page owners, and campaign managers. It is not a tool for administrators - it is a tool that makes every individual editor their own first line of quality control.

   What the editor needs to see
   When an editor logs in, their dashboard should surface the content they personally created or own. (as per editor access rights applicable)

   Broken and 404 pages
   1. Pages I created that are currently returning a 404 error or are broken
   2. Pages that have an incorrect redirect set up
   3. Any pages I own that have no live URL and no redirect in place
   4. Direct links to each page so I can go in and fix it immediately

   Outdated content
   1. Pages I own that have not been reviewed or updated in a defined period of time
   2. A clear signal of how long it has been since the last update
   3. The ability to mark a page as reviewed without making edits, if the content is still current

   Unused images and media
   1. Images and files I uploaded that are not currently used on any page
   2. The file name, upload date, and file size so I can make an informed decision
   3. A way to archive or delete unused files directly from the dashboard

   Unpublished drafts
   1. Pages I have started but never published
   2. The last date I saved the draft, so I can identify ones that have been forgotten
   3. A direct link to open the draft and either publish it or discard it

   Expiring and review-due content
   1. Pages where a review date or expiry date is approaching in the next 30 days
   2. Pages where no review date has been set at all, flagged as a governance gap
   3. The ability to extend a review date or set one if it is missing

   Rule-Based Automation Layer (if possible)
   Defined rules such as:
   1. Draft older than 90 days → archive or notify owner
   2. Redirect chains > 2 hops → auto-flag for cleanup
   3. 404 URLs with traffic → auto-suggest redirect
   4. Orphan pages (no inbound links) → flag or archive

   What the editor does not need to see
   The dashboard should not show content owned by other editors (exception for admins, site managers & super users). It should not show global site statistics. It should not require the editor to filter, search, or configure anything to get to their personal view. When they log in, their issues are the first thing they see.

   Why this is a single solution, not multiple tools
   We considered building separate reports for each of these issues. We decided against it. Separate reports mean editors have to remember to check multiple places. Most will not. A single dashboard that loads at login means the information finds the editor, the editor does not have to go looking for it. This also means one build, one place to maintain, and one consistent experience for all 100+ editors regardless of which site or market they work in.

   Attached are vizualisation ideas- not anything we have as of today.

   As a content editor, I want to see a personalized dashboard when I log in to the CMS that shows me only the content I own that needs attention, so that I can find and fix issues myself, without waiting for someone else to tell me about them.

   This dashboard replaces the generic default view in the CMS for all content editors. It does not replace any existing admin tools or reports. The intent is to move content governance from a reactive, admin-led activity into a proactive, editor-led habit. The dashboard is the trigger for that behavioural shift. This is… more

   •  

   •  

   2 votes

   Vote Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   New  ·  0 comments  ·  Reports  ·  Delete…  ·  Admin →
   How important is this to you?

   Nice to have You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Submit Rating

8. Regenerate Content Graph keys and secrets through Paas portal

   Clients should have the ability to regenerate Content Graph keys and secrets in the self-service Paas portal.

   6 votes

   Vote Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   0 comments  ·  DXP, Hosting & Infrastructure  ·  Delete…  ·  Admin →
   How important is this to you?

   Nice to have You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Submit Rating
   Research & Design  ·  AdminCiara Bergin (Principal Product Manager, Optimizely) responded

   Good news - this idea is now being explored by our product and design teams. We’re researching potential solutions and scoping out what an implementation might look like. We’ll share updates here as our thinking evolves.

9. Implement SRI attributes for injected JavaScript & Styles

   The Optimizely PAAS CMS platform has multiple touchpoints where scripts are injected into the frontend UI. Examples include Optimizely Forms, Content Recommendations, Search & Navigation etc.

   When these scripts are injected into the UI, they are not added with a Sub-resource Integrity attribute. An SRI check allows us to instruct the browser that it should not load a tampered version of a JS or CSS file and can protect users from man in the middle attacks. You can read more about SRI here: https://developer.mozilla.org/en-US/docs/Web/Security/Subresource_Integrity

   This is a commonly reported issue in penetration tests and clients are becoming increasingly more security conscious and request that we make sure SRI attributes are in place. While we can add SRI checks for JS and CSS files that we generate, the files injected by Optimizely lack these attributes. We are left explaining to the customer that we do not control these scripts and styles

   Our desired output would be that scripts and styles rendered by Optimizely code include an SRI attribute.

   The Optimizely PAAS CMS platform has multiple touchpoints where scripts are injected into the frontend UI. Examples include Optimizely Forms, Content Recommendations, Search & Navigation etc.

   When these scripts are injected into the UI, they are not added with a Sub-resource Integrity attribute. An SRI check allows us to instruct the browser that it should not load a tampered version of a JS or CSS file and can protect users from man in the middle attacks. You can read more about SRI here: https://developer.mozilla.org/en-US/docs/Web/Security/Subresource_Integrity

   This is a commonly reported issue in penetration tests and clients are becoming increasingly more security… more

   10 votes

   Vote Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   0 comments  ·  Security & Compliance  ·  Delete…  ·  Admin →
   How important is this to you?

   Nice to have You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Submit Rating
   Future Consideration  ·  AdminMatthew Slim (Product Manager, Optimizely) responded

   Thanks for raising this - just to let you know this is now in our backlog. While we can’t share an exact release date yet, this means it’s planned for consideration in the future. Thanks for helping us prioritize this work.

10. Site-specific Wastebaskets for multisite

    As of now all sites share the same Wastebasket in a multisite. We need site-specific wastbaskets so that only the editors with access to a site (and wastebasket) can go to the site-specific wastebasket and delete content. Closing in to almost 100 sites with extreme amounts of data, our wastebasket is not possible to navigate - even for admins.

    3 votes

    Vote Vote Vote Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Vote

    We’ll send you updates on this idea

    Gathering Feedback  ·  1 comment  ·  Implementation  ·  Delete…  ·  Admin →
    How important is this to you?

    Nice to have You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Submit Rating

11. IP Address restriction in Cloudflare

    It would be great if we could configure an IP Address whitelist in Cloudflare so that we only allow a specific set of source IP Addresses to be allowed to access our DXP instances. This will allow us to block public access to non-production environments

    2 votes

    Vote Vote Vote Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Vote

    We’ll send you updates on this idea

    New  ·  0 comments  ·  DXP, Hosting & Infrastructure  ·  Delete…  ·  Admin →
    How important is this to you?

    Nice to have You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Submit Rating

12. Access restricted for Specific user with expert import

    We need to configure roles in Optimizely to grant specific users permission to use the Import and Export functionality.

    Access must be restricted based on the users’ assigned business units. For example, if a user is assigned access only to Asteco, they should be able to perform import and export activities strictly within the business units (e.g., Asteco and Pactive) aligned with their permissions.

    Users must not have visibility of or access to any other projects beyond their assigned business units.

    3 votes

    Vote Vote Vote Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Vote

    We’ll send you updates on this idea

    New  ·  0 comments  ·  Export / Import  ·  Delete…  ·  Admin →
    How important is this to you?

    Nice to have You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Submit Rating

13. App Insights alerts

    Self-serve creation of alerts in App Insights based on specific thresholds exceeding a limit will help be proactive in responding to potential performance issues or other problems

    11 votes

    Vote Vote Vote Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Vote

    We’ll send you updates on this idea

    Research & Design  ·  0 comments  ·  DXP, Hosting & Infrastructure  ·  Delete…  ·  Admin →
    How important is this to you?

    Nice to have You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Submit Rating

14. Application Insights - be able to sample or filter logged data

    As a customer and implementation partner using DXP I would like either:

    • a built-in tool somewhere, in the DXP portal, optimizely or Azure, to be able to filter out unwanted third party dependencies from being logged to the DXP Application Insights,

    or

    • the permissions to add our own sampling in Application Insights.

    Optimizely DXP injects Application Insights (via required headers) and we cannot opt out of that. We don't have any way to sample the data logged to that Application Insights instance.

    We get alerts about "DXC - Production Application Insight Daily cap reached" on logged data that is mainly third party dependencies injected from marketing tools that we have no control over.
    There is no documentation or best practices at Optimizely on how to implement custom filtering of these.

    We have implemented a custom browserside filter in Optimizely where we can filter out the logging if unwanted third party dependencies. And we need to look up such unwanted dependencies ourselves in App Insights at regular intervals.
    This works well, the number of logged dependencies are now much lower.

    However, it would give us a much better experience and value from the product if it was not forced upon every customer to implement their own filter.

    As a customer and implementation partner using DXP I would like either:

    • a built-in tool somewhere, in the DXP portal, optimizely or Azure, to be able to filter out unwanted third party dependencies from being logged to the DXP Application Insights,

    or

    • the permissions to add our own sampling in Application Insights.

    Optimizely DXP injects Application Insights (via required headers) and we cannot opt out of that. We don't have any way to sample the data logged to that Application Insights instance.

    We get alerts about "DXC - Production Application Insight Daily cap reached" on logged data that is mainly… more

    1 vote

    Vote Vote Vote Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Vote

    We’ll send you updates on this idea

    Gathering Feedback  ·  0 comments  ·  DXP, Hosting & Infrastructure  ·  Delete…  ·  Admin →
    How important is this to you?

    Nice to have You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Submit Rating

15. Visual Builder: When changing style settings or property values in the outline panel, the left preview panel always refreshes

    CMS SaaS: I have just converted my project from using @remkoj/optimizely-cms-nextjs to @optimizely/cms-sdk, but the live preview sync for style settings and property value updates is not as smooth as with @remkoj/optimizely-cms-nextjs.
    Previously, my project worked very smoothly in Visual Builder mode. It only updated the element I changed and did not refresh the entire iframe.
    However, after switching to @optimizely/cms-sdk, whenever I update anything, it always refreshes the preview iframe, resulting in a very poor user experience.
    Is this expected behavior, or am I missing something?

    CMS 13: We’re seeing the same full iframe refresh issue on Optimizely CMS 13. Does Optimizely have any plan or timeline to improve the synchronization logic for smoother partial updates instead of full preview reloads?

    CMS SaaS: I have just converted my project from using @remkoj/optimizely-cms-nextjs to @optimizely/cms-sdk, but the live preview sync for style settings and property value updates is not as smooth as with @remkoj/optimizely-cms-nextjs.
    Previously, my project worked very smoothly in Visual Builder mode. It only updated the element I changed and did not refresh the entire iframe.
    However, after switching to @optimizely/cms-sdk, whenever I update anything, it always refreshes the preview iframe, resulting in a very poor user experience.
    Is this expected behavior, or am I missing something?

    CMS 13: We’re seeing the same full iframe refresh issue on Optimizely CMS… more

    1 vote

    Vote Vote Vote Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Vote

    We’ll send you updates on this idea

    New  ·  0 comments  ·  Editing (Content)  ·  Edit…  ·  Delete…  ·  Admin →
    How important is this to you?

    Nice to have You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Submit Rating

16. Copied pages to be Draft rather than Published by default

    Global Digital Marketing Director.

    When I copy and paste a page in the tree its status is always published or maybe it is the same of the page it is being copied from. I want to make the status of that page unpublished by default and then publish is manually later on, without requiring additional development work.

    There have been other threads about this in the past eg https://world.optimizely.com/forum/developer-forum/CMS/Thread-Container/2018/5/copy-and-pasted-pages-always-have-published-status/

    3 votes

    Vote Vote Vote Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Vote

    We’ll send you updates on this idea

    Gathering Feedback  ·  0 comments  ·  Editing (Content)  ·  Delete…  ·  Admin →
    How important is this to you?

    Nice to have You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Submit Rating

17. Disable Allowed Content Types Description in CMS 12 Edit View

    In CMS 12 Episerver Edit interface we noticed a new feature: above all ContentArea fields, a description appears listing allowed content types (Refer attachment).We’d like to have this removed. It seems to add more confusion than clarity for our editors. We already enforce allowed content types using the [AllowedTypes] attribute in code, so displaying the full list in the UI—especially including unrelated options like Episerver Forms elements—is unnecessary and distracting.
    This description wasn’t present in CMS 11, and we would prefer to maintain that cleaner editor experience.

    •  

    9 votes

    Vote Vote Vote Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Vote

    We’ll send you updates on this idea

    Committed  ·  2 comments  ·  Editing (Content)  ·  Delete…  ·  Admin →
    How important is this to you?

    Nice to have You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Submit Rating

18. Add Custom .NET Core Event Counters to CMS

    In order for development teams to identify development issues within their implementation they need to be able to see under the hood of their implementation and inspect the qualitative metrics of their implementation.

    Additionally, within our production environment, we should have a variety of metrics available to us to diagnose the quality of an implementation. These metrics would help guide our investigation as the

    Currently, this is missing and we have major issues with partner and customer implementations because of it and our MTTR within our production environments is protracted because of the lack of this information.

    We also need co-locality of analytics. We need metrics to be co-located in the same system to do time-based analysis (such as correlating response time spikes to other internal metrics to identify cause) to prevent us from having to cross systems.

    We also need all of these analytics accessible by the customer because otherwise we end up owning the analysis burden because of lack of access by the partner and customer dev teams.

    This idea is really a request for "the entire suite" of metrics that are necessary. I have not enumerated every metric that are needed as of yet, but I could assist with that exercise.

    In order for development teams to identify development issues within their implementation they need to be able to see under the hood of their implementation and inspect the qualitative metrics of their implementation.

    Additionally, within our production environment, we should have a variety of metrics available to us to diagnose the quality of an implementation. These metrics would help guide our investigation as the

    Currently, this is missing and we have major issues with partner and customer implementations because of it and our MTTR within our production environments is protracted because of the lack of this information.

    We also need… more

    1 vote

    Vote Vote Vote Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Vote

    We’ll send you updates on this idea

    Gathering Feedback  ·  0 comments  ·  Graph  ·  Delete…  ·  Admin →
    How important is this to you?

    Nice to have You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Submit Rating

19. Ability to smoke-test more than 1 site during smooth deploy (slot domains)

    Ability to smoke-test more than 1 site during smooth deploy (slot domains)

    As a CMS developer and QA specialist we want to be able to smoke-test multiple sites so that we can detect potential issues on all our sites during deployment with DXP Cloud Platform to our multi-site CMS platform.

    When we deploy to PREP/PROD we get a temporary SLOT to run our smoke-tests against. For example:

    https://projectidprep-slot.dxcloud.episerver.net/

    https://projectidprod-slot.dxcloud.episerver.net/

    These are the default URL provided by Optimizely and are configured on the first website. We would like to be able to smoke-test multiple sites on the SLOT instance.

    We could configure additional domain names on each site like so:

    https://prep-slot.example-site123.com

    https://prep-slot.another-example-site123.com

    https://www-slot.example-site123.com

    https://www-slot.another-example-site123.com

    However, I have been informed that this also requires a change on your end (Azure/DXP) in order to support multiple domain names on the SLOT instance during deployment.

    Ability to smoke-test more than 1 site during smooth deploy (slot domains)

    As a CMS developer and QA specialist we want to be able to smoke-test multiple sites so that we can detect potential issues on all our sites during deployment with DXP Cloud Platform to our multi-site CMS platform.

    When we deploy to PREP/PROD we get a temporary SLOT to run our smoke-tests against. For example:

    https://projectidprep-slot.dxcloud.episerver.net/

    https://projectidprod-slot.dxcloud.episerver.net/

    These are the default URL provided by Optimizely and are configured on the first website. We would like to be able to smoke-test multiple sites on the SLOT instance.

    We could… more

    5 votes

    Vote Vote Vote Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Vote

    We’ll send you updates on this idea

    Gathering Feedback  ·  2 comments  ·  DXP, Hosting & Infrastructure  ·  Delete…  ·  Admin →
    How important is this to you?

    Nice to have You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Submit Rating

20. 25 Production Service Buses Broken

    We need to define what "working" means for a service bus so that reliability engineering can maintain reliability based on these metrics.

    When a service bus no longer functions, reliability engineering should be equipped with the capacity to upgrade service buses in order to meet a component-specific SLA.

    We need product management to define what "working" means for a service bus so reliability engineering can respond appropriately when a service bus is "broken" rather than having to go back to PM as though we need a exception for every broken service bus.

    We also need monitoring in place to ensure that we receive alerting when the metrics of "broken" happen. This allows us to be proactive regarding broken infrastructure and has the positive outcome of proactively reducing ticket count.

    The attached report shows all 25 broken SBs. The definition of "broken" in this case is a SB with a Count of Active Messages > 1000 for more than 30 consecutive minutes.

    We need to define what "working" means for a service bus so that reliability engineering can maintain reliability based on these metrics.

    When a service bus no longer functions, reliability engineering should be equipped with the capacity to upgrade service buses in order to meet a component-specific SLA.

    We need product management to define what "working" means for a service bus so reliability engineering can respond appropriately when a service bus is "broken" rather than having to go back to PM as though we need a exception for every broken service bus.

    We also need monitoring in place to ensure… more

    • 

    1 vote

    Vote Vote Vote Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Vote

    We’ll send you updates on this idea

    Gathering Feedback  ·  0 comments  ·  DXP, Hosting & Infrastructure  ·  Delete…  ·  Admin →
    How important is this to you?

    Nice to have You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Submit Rating