0
Category:
STATUS DETAILS

Comments

10 minutes to fix; 2 hours to let the world know that it will not be fixed.

Category:

Agree, way too small to allow for effective planning.

Category:

This is working for us on the "new" sales app : Launch($"ms-apps-sales://{EnvironmentURL}_{SalesHubAppId}?tenantId={Host.TenantID}&appType=AppModule&forceOfflineDataSync=true&restartApp=true&isShortcut=true&openApp=true&etn=contact&pagetype=entityrecord&id={contactId}")

Category:

we need this feature to be included in nearest versions like 48 or 49

Category:

Guy,This is just a business process change (the way this is worded). Your two lines that specify old and new code behavior are word for word identical (rightly so). I see your approach as a solution, but no change to Planning Optimization is needed. In addition to your planner following up manually with BOM changes I’d like to see a Plan Group of Superseding limited to only 2 lines since the priority value is confusing and now redundant.However, I’d prefer to see the “Use-up Engineering Change” capability seen in so many other ERP solutions. Here, effectivity dates are used and kept up to date (a change inside Planning Optimization MPS) to the date where MRP projects a transaction driving inventory of the old item in the Planning group negative. This does imply a likelihood of a small residual inventory of the old item, but so does your recommendation – easy to report on. Multi lines (e.g. these 2 new items supersede 3 items on the old BOM) would simply leverage phantom items in the plan group. No change to Planning Optimization and no manual step, A new checkbox column on the old and new BOM lines set to Use-up equals true and a new column declaring the same Use-up group (Plan Group could work, but why not).

Category:

I completely agree, having the ability to reinstall a previous version of an extension without needing to modify the version number would be very useful. It would make rollback and testing much simpler and reduce confusion around version management.

Category:

This is really important and face this issue too

Category:

We received the same feedback and looks like this is on the radar for Wave 1 2026.

Category:

This should be option in the original product Design, Many other ERPs provide this functionality as out of the box. we are forced to do custom code.

Category:

Additional clarification: Although voice workstreams can technically be configured to route calls to agents in the Busy state, in our environment we intentionally use Busy to indicate that an agent is already engaged in a live chat, so voice should not route to them in that case.When record-based assignments (like Case or Email) also push agents to Busy, this logic is disrupted, because it falsely marks the agent as busy even when they aren’t handling a live interaction.This makes it difficult to maintain clear presence logic across channels (e.g., Voice should only avoid agents who are busy with chats, not those assigned to backend records).

Category:

  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 500