Name: Extending the Visit Print Form in SAP Sales Cloud Version 2
Uploaded: 2026-6-1
Duration: 665 s

Share feedback

<p>We are aware of intermittent issues in accessing the learning content</p>

We are aware of intermittent issues in accessing the learning content

Personalize your learning.

Why create an SAP account?

Enhance your learning experience

SAP Learning

Choose your subscription

Manage your subscription

Live Sessions

Hands-on Practice

Certification

My Learning

Ready to start learning?

This browser is not supported

Please try again later

Sorry, we encountered an error

Try again or reset results to continue browsing

We didn’t find what you’re looking for

To continue, please log in

Your session has timed out

Validate your skills and learning by completing the certification exam and gain a highly recognised accreditation.

Book your certification exam

Complete the assessment to validate your SAP PartnerEdge competency qualifications.

Ready to take your assessment?

Learn about the key features and essentials in the latest release to help you prepare for the Stay Certified assessment.

Prepare for assessment

Learn new skills you need at your own pace with our bite-sized lessons.

Prepare for certification

In your My Learning account you can view your certification and learn how to take your Stay Certified assessment.

Ready to take your Stay Certified assessment?

Explore {title} at SAP Learning. Find out more!

Assessment

Course Completion

Knowledge Badge

Overview

Support Resource

Certification Exam

Theoretical Exam

Schedule

External Course

Practical Exercise

Practical Test

External Hands-On

External Resource

Learning Journey

Learning Journey Assessment

Lesson

Live Session

Practice System

Hands-on Practice for {title}

Quiz

Scenario Based Assessment

Course Assessment

Course

Stay Certified

Subscription

System Based Assessment

Test Out

Unit

Video

Video Playlist

Week

Want to remove this from your Learning List?

Your exclusive access to the SAP Learning Hub, event edition is ready. <link>Start learning now.</link>

Access activated

You can now register for free Live Sessions.

<div><div><div><div><div><div><div><div><div>This video walks you through the analysis and implementation of a complex side-by-side extension scenario to extend the visit print form in SAP Sales/Service Cloud Version 2. The video demonstrates creating a custom field, implementing extension logic in a Node.js app, hosted on SAP BTP, which gets triggered by a webhook, and finally, adapting the Visit print form template with the Adobe LiveCycle Designer to display the new data.</div><div><br></div><div>URLs in the video:</div><div>Related Blog and Script Snippets: <a target="_blank" rel="nofollow noopener noreferrer" href="https://url.sap/97tud5">https://url.sap/97tud5</a></div><div>Blog on Debug Sheet: <a target="_blank" rel="nofollow noopener noreferrer" href="https://url.sap/rdoejn">https://url.sap/rdoejn</a></div><div>Blog on Debug Monitor: <a target="_blank" rel="nofollow noopener noreferrer" href="https://url.sap/ehomup">https://url.sap/ehomup</a></div></div></div></div></div></div></div></div></div>

Extending the Visit Print Form in SAP Sales Cloud Version 2

In this video, we'll discover how to add job titles of contact persons to the visit summary print form in SAP Sales Cloud version 2. To achieve this, we have to overcome several challenges, making this use case a perfect example of a more complex scenario leveraging side-by-side extensions. But first, let's make ourselves familiar with the topic by looking at a sample visit. Here, we can see four attendees listed. When opening the details screen of a contact person, we can see the job title, which is maintained in the contact person's master data. Let's have a look at the visit summary. Currently, it doesn't display job titles. In the next step, we want to confirm whether this data is missing in the form's underlying data source. We can leverage a special debug form that displays the full XML data passed to the Adobe Document Services. This debug form needs to be uploaded via the Maintain Form Templates setting. Additionally, we have maintained some form template selection rules to allow switching between templates based on a string in the visit's title. You can find more information about the debug sheet in this blog. By changing the visit's status back to In Process, we can edit the description and add the string that selects the debug template. When we check the visit back in and view the summary, the debug template displays the raw XML data. Looking at the attendee data, we can confirm that the job title is not included. Hence, we cannot simply open the form in Adobe LiveCycle Designer and make the fields visible. We have to make the job titles available in the data source first. This will require the following steps. We'll extend the visit object with a custom field. We'll leverage a small Node.js side-by-side extension app where we place the logic to fill the field. This logic will be triggered by a webhook that we'll set up. And finally, we can adapt the print form to display the job titles, which also requires a little special tweak. Let's explore the options in the Extensibility Administration setting. Unfortunately, the visit object only supports extensions at the header level. There's no attendee node, which would be beneficial for our use case. Let's see if there's something at the header level that can help us. The Reference Fields Usage looks promising. Unfortunately, it only supports 1:1 associations, such as the primary contact. No surprise, we don't find a 1:n relationship to the visit attendees here. That means our only way forward is to create a custom field at the header level where we store multiple job titles and their corresponding contact person IDs in a structured format. Sounds interesting? Then let's begin! Let's create a new custom field on the visit header. We'll name it Print Form Contact Job Titles. We can leave the label as is, since this field won't be visible on the user interface. The data type will be String. For this demo, we'll set the length to 300 characters. Depending on the typical number of attendees and the length of job titles in your system, you may assign a larger number. Next, we set up the external hook. Give it a meaningful name and description. Because we only update an extension field and don't require validations, we use the Post-Hook for our scenario. Lastly, we have to enter the communication details. the API path where the extension logic listens for messages, and the communication system that covers the hostname and authentication. This might be easier after deploying the extension app. After creating the hook, you can download schemas and sample payloads using these buttons. Now, let's look at some sample payloads and the Node.js app in Visual Studio Code. The downloaded sample gives a good overview of the structure. Here we can see the entity and the main parts, the before image and the current image, and some additional context information. However, as with adapting print forms, it's always better to look at real data. Therefore, let's switch to a real example. Here, we have the current image at the top. Let's scroll down to the attendees. When comparing the fields with the downloaded sample, we can see some differences. This confirms that it's always good to look at real data. Here we can also see the created extension field, which is of course still empty at the moment. You can find more information about how the payload was extracted in this blog. Now, let's have a look at the server.js, which contains the main logic. You can find the script snippet in this blog. The server handles requests sent via the post method at the endpoint we maintained in the webhook. After some basic checks and logging, it reads all attendee IDs from the current image. Then, the function getContactPersonJobTitles is called. This retrieves the full details for each attendee, extracts their job titles, and combines them into a single string with the desired pattern. Please note that we use a BTP (Business Technology Platform) destination to connect to the REST API. This has the advantage that the actual target host and credentials don't need to be maintained in our app, which makes it more secure and is the recommended way. The return string is then incorporated into the required response body structure to populate the custom field. Alright, let's deploy the app. If you're not already logged into your subaccount, log in. We use "cf login --sso". That allows logging in with a temporary key instead of a username and password. Then we can run "cf push". This may take a short while. After the first deployment, the app will not be able to start successfully because the destination is still missing. You must create the destination and bind it to your app with these two commands. After that, you can restage your app or simply deploy it again with "cf push". After successful deployment, the app is available in the Cloud Foundry space in the BTP subaccount. Here, we can also see the bound destination. Let's give the side-by -side extension a try. We open a visit and change a field. For instance, the status. Although the field is not visible in the UI, we can check whether it was properly updated by calling the visit's REST API directly in the browser. There it is. Now, we can take care of the print form. In Sales Cloud V2, under the Maintain Form Templates setting, we download the standard template for the visit summary. After extracting the zip file and renaming the form template, we open it in the Adobe LiveCycle Designer. The warning tells us that the data source description could not be found. Fixing this is the first of two housekeeping steps. We can do that in the Data View palette under Connection Properties. Here we get the same warning again. The XSD file from the zip contains the system's latest data source description, including our custom field. The second housekeeping step is loading sample data. We load the sample data that we extracted with the debug print form earlier. Also change the preview type from interactive to print form one-sided. Let's preview the form with the sample data. The attendee table displays three contact persons and an external email address. We can find them in the XML accordingly. Here, we can also see the extension field with the formatted ID job title string. Let's replace the participation column and show the job titles instead. First, we change the caption and the cell names. In the cell of the body row, we also remove the data binding. Then we come to the core implementation. We place the script in the attendee table element. As we can see, the table or, to be more precise, some child objects already contain some scripts. Hence, we must be careful when adding the new script. Disable displaying child objects in the script editor and change the event filter to Initialize. Ensure that the language is set to JavaScript. Then we add the script. It consists of an object variable that stores the IDs and job titles, some functions, and finally the two lines that call these functions. InitJobTitles reads the extension field's content directly from the data source without an additional bound field. The function getValueFromDataSource safeguards access to the data source in case the field doesn't exist. Then, the IDs and job titles are parsed and stored in the object. The function enrichJobTitleTable loops through the table that already contains all bound data at the time of the initialize event. Since the attendee display ID is not bound to any cell, we must read it from the data source. With DataNode, we can access the data source record bound to the corresponding row. Finally, the job title for the attendee display ID is looked up and, if it was found, populated in the job title cell. You can find the latest script snippet in this blog. The final result looks like this. Now we can upload the form as a new template. Back in the maintain form template setting, create a copy of the pre-delivered template and give it a meaningful name and description. Then we can go to edit and upload our modified template. Remove the existing template and upload the new one. In the last step, we navigate to select form templates and create a new rule so that the job title print form is selected as the default one if no other rule matches. Back in our sample visit, we can finally see the entire extension end-to-end in action and view the visit summary. Thanks for watching!