Business application form to application service

[dvass0107]

Hello all,

There are some attributes that are in Business application need to be in Application service.

can we use same attributes of business application form to application service ?

Regards,
Srinivas

[Dr Atul G- LNG]

Hi @dvass0107 

What are these values? Did you try using the dot walk from BA to AS? Do you have any screenshots to share?"

[debendudas]

Hi @dvass0107 ,

According to the OOTB configurations, Business Applications and Application Services are mapped to each other using the Relationship (cmdb_rel_ci).

If you want to cascade the values of the Business Application field to the Application Service (for example, the ownership details) you can write a Business Rule or a Flow or a Fix Script to pass the Business Application field values to the Application Services associated with the Business Application. However, ensure that one Application Service is not mapped to multiple Business Applications, as this may cause undesired field override issues in the Application Service.

If this solution helps you then, mark it as accepted solution ‌‌✔️ and give thumbs up 👍! 

[AndersBGS]

Hi @dvass0107 ,

 can you please elaborate on your question? Your question is not clear.

[AJ-TechTrek · Accepted solution]

Hi @dvass0107 ,

As per my understanding, Below solution and approach will help you.

1. Can we “use” the same attributes?


Not directly in the sense of them being literally the same field.
* Business Application (cmdb_ci_business_app) and Application Service (cmdb_ci_service_discovered) are two separate tables → each has its own set of fields.
* If you want the same kind of data (e.g., Business Owner, Service Owner, Criticality, etc.) to appear on both:
* You add equivalent fields to Application Service.
* They won’t automatically be linked or synchronized just by default.

2. How to keep them in sync or reused?
There are several ServiceNow-standard ways, depending on what you want

Option A: Inherit via relationship
* Establish a relationship:
* e.g., Application Service → depends on → Business Application.
* Then, when you need the Business Owner on the Application Service:
* Reference the value from the related Business Application in UI (dot-walk).

* Example:
* In a form or list: business_application.business_owner
Pros: no duplication.
Cons: only works if you keep the relationship consistent.

Option B: Copy fields during creation
* When you create an Application Service, copy values from its related Business Application (using a Business Rule, Flow Designer, or Script).
* Keeps them as independent fields, but initialized.
Pros: simple, quick.
Cons: needs logic to keep updated if source changes.

Option C: Shared dictionary extension (advanced)
* Create a parent table with shared attributes, extend both tables from it.
* Rarely done in standard CSDM, because CSDM intentionally keeps these tables separate.

3. Which is recommended in CSDM?
* The CSDM model: keep Business Application in Design domain; Application Service in Technical domain.
* Use a relationship (Depends on::Used by) between them.
* Use dot-walking to reference common attributes (like Owned by, Managed by, etc.).
* Only create custom fields directly on Application Service if you really need different / runtime-specific data.

Please appreciate the efforts of community contributors by marking appropriate response as Mark my Answer Helpful or Accept Solution this may help other community users to follow correct solution in future.
 

Thank You
AJ - TechTrek with AJ - ITOM Trainer
LinkedIn:- https://www.linkedin.com/in/ajay-kumar-66a91385/
YouTube:- https://www.youtube.com/@learnitomwithaj
Topmate:- https://topmate.io/aj_techtrekwithaj (Connect for 1-1 Session)
ServiceNow Community MVP 2025