Idea ID: 1684298

configure pause subscription at catalog or offering level

Status : Delivered
over 2 years ago

•Brief Description
configure pause subscription at catalog or offering level
•Benefits / Value
this allows different models of acting towards failures in different Designs/offerings.
organizations are not right level to define pausing. if a subscription should be right away failing or should be fixed by an operator is usually to be decided based on the Design and what it is good for.
currently it is impossible to allow designs to fail when you have other offerings/designs that must be handled by pausing
•Design details
Move/add a function at minimum at catalog level that defines if subcriptions will pause or fail.
probably catalog is the right level between micromanagement and flexibility.
although at catalog level might grow the amount of catalogs exponentialy taking the matrix of different settings into account(permissions, potentially notifications, approval policies)
based on the growing amount of potential settings it might be a better way to set all at offering level.
there is anyway a lot that needs to be configured at offering
maybe it is good to make a standard set of Configurations for a CSA instance for newly created offerings
this would allow an CSA admin to sepcify best match for most new offering cases


Cloud Svc Automation
  • The solution is delivered as part of HCMX. The configuration required for Pause-and-Resume can be done at a more granular level. The customer can configure this at the designer level than the organization level in HCMX 

  •   Hi Michael,

    We wanted to learn a bit more about how you create service designs and the process of creating offering and publishing them in catalog that might be of relevance to Pause on Failure configuration.

    Would you please share some insight for the following questions? They would help us to understand better how customers are working with our product. Thanks as always for your help and collaboration!

    1. Can you please share some example of services where pausing on failure is not desirable (even though the general principle for failure handling is to pause on failure, for other services in general)?
    2. If an offering manager  configures whether to pause on failure, at the offering level (instead of being done at the design level), does the offering manager need any knowledge about the design to decide whether pausing on failure would be the right choice for that underlying design? Or is it reasonable to think that it does not matter how the design is written (i.e. whether the actions in the design are implemented as rerunnable or not), it is assumed that operators will figure out whatever they need to do to resume the processing, by either choosing to rerun the failed action (which would require to undo everything done so far and then run the action again, if the action was not implemented to support rerun) or skip the failed action (after fixing the step that failed and potentially performing remaining steps in the flow manually) to execute the next action?
    3. Follow up from #2, if the offering manager does need to be aware of implementation of service design, is it reasonable to assume that they will have such knowledge or they will be told by someone who knows the detail as part of the “process” of offering creation?
    4. If multiple offerings are created from a design, could there be scenarios where some of those offerings should pause on failure while others should fail and not pause?
    5. In your experience service designs which desires pause on failure mode of failure handling, do they actually make actions rerunnable with explicit logic so that the failed actions can actually be run again, which reduces the manual work needed from operators so that the operators do not need to undo ALL the steps from the beginning to the failed step manually before rerunning the flow  during resume?
    6. Given that resuming a paused instance now allows skipping the failed action and start executing from the next action, do you see rerunning a failed action not used by operator much and rather relying on skipping failed action more?

    Best regards,


  • Hi As this is mainly a feature that addresses ability to operate Services, the impacted Customer are we. As this is not exposed problem  to the end users, they will not recognize it.

  • Hello Everyone (@Alberto Belotti ,@








  • Hi Nivedita, that makes total sense. i totally support this