Introduction Flexible Workflow in both S/4HANA Cloud and on-premise (and everywhere in-between) is the recommended way of constructing simple workflows. In this blog, I want to talk about two programmatic methods of providing value helps for custom Condition parameters in S/4HANA Cloud. Standard flexible workflows are provided for a number of different scenarios in S/4HANA Cloud. I will be looking at the Supplier Invoice scenario, but the use of custom conditions is common across different scenarios. First I’ll talk a bit about conditions in flexible workflows, so if you’re only interested in value helps, feel free to skip to the end! Flexible Workflow Conditions When you create a new Flexible Workflow, you can specify Conditions at both the Workflow level and the Step level. The Workflow-level Conditions let you create workflows for different situations; e.g. you could specify one workflow for Supplier Invoices in certain company codes and another workflow for other companies. You could also specify that the total value of your Supplier Invoice must, for example, be at least 1,000 EUR before the workflow is applicable. Standard Workflow-level (Start) Conditions for the Supplier Invoice Flexible Workflow The Step-level Conditions let you decide if a particular step in a workflow should execute, or whether it should be skipped, with the workflow then automatically preceding to the next step. For example, one of your companies might require an extra approval step in the middle of multi-step workflow, while the others do not. You could create multiple flexible workflows and use a workflow-level condition to decide which workflow gets triggered, but this means that you would have to maintain multiple workflows when requirements change. It makes more sense to have a single workflow for all your company codes, but to create a step-level condition saying that a particular step is only applicable for a particular company, so that Supplier Invoices in other companies would just skip this step. What happens if you want to add a custom condition to a flexible workflow? Our requirement is for the Supplier Invoice workflow to only execute for a certain Accounting Document Type. This condition is not offered as standard, so we will have to use one BAdI to define the condition and another to evaluate it. Defining a custom Condition BAdI definition SWF_WORKFLOW_CONDITION_DEF can be implemented to define custom conditions at both the Workflow and Step level. Using the Custom Logic app, we create a new enhancement implementation with the following values New Enhancement Implementation Although we pick a Business Context when we create the implementation, this BAdI is a generic one, shared by all flexible workflows, so we need to add a filter on the Scenario ID to specify which one we want to use. In this case, it is WS00800251 (Workflow for Blocked Invoice). We now want to add our new condition to the CT_CONDITION table: * (Accounting) Document Type condition ct_condition = VALUE #( ( id = 'DTP' subject = 'Accounting Document Type of Supplier Invoice is' type = if_swf_flex_ifs_condition_def=>cs_condtype-start_step ) The ID of the condition can be anything you like, the subject is the text that will be shown in the Conditions drop down when configuring a Flexible Workflow, and the type specifies whether the condition is available at both Workflow and Step level (if_swf_flex_ifs_condition_def=>cs_condtype-start_step) or just the Step level (if_swf_flex_ifs_condition_def=>cs_condtype-step). We now need to add a parameter for this condition to the CT_PARAMETER table, so that the user configuring the workflow has somewhere to enter the required Account Document Type value. * Parameter for Workflow level condition - Accounting Document Type ct_parameter = VALUE #( ( id = 'DTP' name = 'Accounting Document Type' xsd_type = if_swf_flex_ifs_condition_def=>cs_xstype-string mandatory = abap_true ) The ID here is the ID of the Condition that was added to the CT_CONDITION table above; it is not an identifier of the parameter itself. The name field serves that purpose, as well as being the text that appears in the input box for this parameter in the workflow configuration app. The xsd_type field allows for a broad selection of types, but doesn’t allow for things like length specifications for strings or decimal places for numbers. Publishing this logic is enough to get our new condition and its parameter appearing as an additional option in the Start Conditions dropdown in the Flexible Workflow app. New condition available for selection New condition with parameter The Accounting Document Type value can be manually entered into the new parameter field and the required functionality is achieved. Note: whether or not this new Condition is met for a particular Supplier Invoice (and therefore whether the workflow will start) requires an additional BAdI implementation (SWF_WORKFLOW_CONDITION_EVAL), which has been covered in a number of other blogs. Providing Value Help Although manually entering an Accounting Document Type is adequate for setting up the workflow, it would be useful to provide a value help on our new parameter so that the user can find the value they want without having to know its code. There are two ways to do this, depending on whether one of the standard SAP-supplied conditions already provides a value help for the same type of field. Value help available in standard condition For example, there is already a standard condition for Supplier Invoice workflows called ‘Company code of supplier invoice is’. If we had wanted to add a custom condition whose parameter required a company code value, we could have reused this value help in our own parameter as long as we knew the name of the data dictionary type that the standard parameter was using. This requires a bit of educated guesswork, since we cannot see how SAP populates these value helps if we’re using S/4HANA Cloud. (In an on-premise system, we can put a breakpoint in the BAdI implementation and debug the standard code around it to locate the internal table that holds association between value helps and data dictionary types) As you can probably guess, the data dictionary type used by the standard parameter for the Company Code is BUKRS. If we specify this as the DDIC_TYPE field in the CT_PARAMETER table record, the value help is provided. ct_condition = VALUE #( ( id = 'BLOG_CC_EXAMPLE' subject = 'Another Company Code condition is' type = if_swf_flex_ifs_condition_def=>cs_condtype-start_step ) ). ct_parameter = value #( ( id = 'BLOG_CC_EXAMPLE' name = 'Company Code again' xsd_type = if_swf_flex_ifs_condition_def=>cs_xstype-string ddic_type = 'BUKRS' ) ). Reuse of Company Code value help New value help required It’s more likely that you need a new value help for your new condition. In our example, a value help for the Accounting Document Type is not available in any standard conditions. In order to provide a new value help, you need to know a field that is available in an OData service which already has the value help attached to it. The best way to find such a field, at least when you’re using S/4HANA Cloud, is to go to an app where you know such a field is available and use the developer tools in your browser to work out what the OData service, the EntitySet and the Property are. Note that you don’t want the EntitySet and Property that actually provide the value help values, but the EntitySet and Property that the value help is attached to. This doesn’t have to be a value help provided by a CDS view, as long as the value help is provided by the OData model (i.e. not manually coded into the UI5/JavaScript). For the Accounting Document Type field, I used the following values when filling in the CT_PARAMETER record: ct_parameter = VALUE #( ( id = 'DTP' name = 'Accounting Document Type'(908) xsd_type = if_swf_flex_ifs_condition_def=>cs_xstype-string service_path = '/sap/opu/odata/sap/FAC_GL_DOCUMENT_POST_SRV' entity = 'FinsPostingGLHeaders' property = 'AccountingDocumentType' mandatory = abap_true ) The service_path field contains the path to the OData service, the entity field contains the EntitySet name (not the EntityType – I spent a while hitting my head against the desk until I worked this out!) and the property field contains the property of the entity to which the required value help is attached. Publishing this code then attaches a value help pop up to our new condition’s parameter. When you select a value in the value help pop up, you will also see the textual description of the code shown in the parameter field, retrieved through the standard OData model: