Skip navigation
Share This:

BMC Atrium Orchestrator Remedyforce Integration: Creating Incident in Remedyforce through BMC Atrium Orchestrator

This blog entry talks about using BMC Atrium Orchestrator (AO) to interact with BMC Remedyforce. First a detour on SFDC web-services and let’s see how an Incident can be created just by SFDC web-services. You can download enterprise WSDL from SFDC and send a login request as shown below. Just make sure, either IP of the machine making this request is white listed on SFDC or you pass security token along with password in the call below. Response returned has two important pieces of information, one SessionID which by default lasts for 2 hours and ServerURI which you would call to create the Incident. SessionID needs to be passed with every other interaction you would have with SFDC. 


<soapenv:Envelope xmlns:soapenv="" xmlns:urn="">
<urn:password>password (+ optional security token)</urn:password>



<soapenv:Envelope xmlns:soapenv="" xmlns="" xmlns:xsi="">
<serverUrl></serverUrl> <sessionId>00D90000000xk7M!AQ0AQEeXrk0dYe6.SurOqu.PQnhcp7v7s6yijjNXBgEKhxxMIRoVPnXdyeREjcSOTQUoPchceKx6_jgv8OL6uHs4SzFE8UaE</sessionId>
<!--Skipped for brevity -->



Please see below Incident creation request and the response. Category ID and Client ID are SFDC internal IDs of these objects and we would see later how they can be obtained.



<soapenv:Envelope xmlns:soapenv="" xmlns:urn="" xmlns:urn1="">
<urn:SessionHeader> <urn:sessionId>00D90000000xk7M!AQ0AQEeXrk0dYe6.SurOqu.PQnhcp7v7s6yijjNXBgEKhxxMIRoVPnXdyeREjcSOTQUoPchceKx6_jgv8OL6uHs4SzFE8UaE</urn:sessionId>
<urn:create xmlns:xsi="">
<urn:sObjects xsi:type="urn1:BMCServiceDesk__Incident__c"> <BMCServiceDesk__IncidentDescription__c>Some_Description</BMCServiceDesk__IncidentDescription__c>



<soapenv:Envelope xmlns:soapenv="" xmlns="">
<!--Skipped for brevity -->



Now let us go back to Atrium Orchestrator. There is an OOTB adapter called bmc-ao-adapter-remedyforce-actor which can be used to interact with Remedyforce. It interacts with SFDC using web-services.

Here is one sample configuration for bmc-ao-adapter-remedyforce-actor:


Once adapter is up and running, just create a new process and add “Create Objects” process from ‘AO-AD-BMC-Remedyforce’ to your process. Specify name of your adapter and have XML similar to this as objects value. Make sure its type as XML.

a    <BMCServiceDesk__FKCategory__c>a17900000056iDOAAY</BMCServiceDesk__FKCategory__c >

If you now run your process, you will see incident created in Remedyforce with Category whose id is a17900000056iDOAAY and client id corresponding to user id 00590000002wYCuAAM. As we said earlier, these are internal SFDC ids and not known to you. But code below shows APEX code to create an Incident by first fetching appropriate Category and User.

// Fetch the category using SOQL
BMCServiceDesk__Category__c category = [ select Id, Name from BMCServiceDesk__Category__c where Name = 'Email' Limit 1];
// Fetch user to be used as Client ID for Incident using SOQL
User user = [ select Id from User where username = ''];
BMCServiceDesk__Incident__c i = new BMCServiceDesk__Incident__c (
BMCServiceDesk__incidentDescription__c = 'Incident_Through_BMC_Atrium_Orchestrator'
i.BMCServiceDesk__FKCategory__c = category.Id;
i.BMCServiceDesk__FKClient__c =;

Now similar to “Create Objects” there is also a process called “Find Objects” in ‘AO-AD-BMC-Remedyforce’. You can use this process to fire any SOQL query. So you can have your process look something similar to this. You can fire 2 SOQL queries to get ID of the category you want to assign to Incident and ID of user who would be client ID for the Incident and pass these IDs in the Original “Create Objects” XML rather than hard-coding those values.


You can download the AO module having the process for above example. Download module

Yogesh Ketkar

Share This:

This blog discusses a very common scenario during Remedyforce implementations. Companies often want that Issues related to HR should not be seen by IT support staff. Issues related to Finance should be seen only by Finance support staff etc. There are a few ways this can be achieved; before discussing them, let me take a small detour and talks about SFDC security model.

There are 3 ways you can control data access in SFDC. Object-Level security, Field-Level security and Record-Level security. Object-Level security deals with giving read, read-write or no-access at all to instances of a particular object say Incident. Field-Level security is same but applies to particular fields of an object. Both these models are captured either in a profile or a permission set which in turn gets assigned to a user. These are crude or blunt ways of doing access control, are very useful in certain cases, but not really useful for the case we are discussing. We are certainly not talking about say hiding all instances or certain attributes of Incident object from a particular set of users.

Once these 2 methods are out of way, let us now talk about how Record-Level security can help us achieve what we want. Every object in SFDC has an organization-wide default setting, which can be private, public read-only or public read/write. Choosing what default you should have for an object is simple. Even if you have one instance of the object you want some user(s) not see, this setting should be private. Even if you have one instance of the object you want some user(s) not edit, this setting should be public read-only else it should be public read-write. So no wonder, org-wide default setting for Incident object (API Name: BMCServiceDesk__Incident__c) is private as you don’t want incidents created by every user to be seen by every other user. Organization-wide default is the starting point in Record-Level security. “Role Hierarchies”, “Sharing Rules” and “Manual Sharing” also control Record-Level security. One important thing to note is Record-level sharing settings can only be used to grant more permissive access to records and can’t be used to restrict access to records. So starting from most restrictive org-wide mode of private for Incident object, you can use other Record-level sharing rules to grant access to certain instances of Incident object to some users.

Let us take a very simple example. In SFDC platform, every instance of an object has a Creator and an Owner. Both Creator and Owner of an object have complete access to the object (I am ignoring the cases such that Owner belongs to a profile which is not given Object-Level security for that object. Well, SFDC doesn’t allow setting Owner to an object who doesn’t even have READ permission on that. But you get the point. We anyway can ignore this in the context of Incident object). Creator can’t be changed, but Owner can be changed. That is why, Incident creator (ServiceDesk Client) and person working on the Incident (ServiceDesk Staff) can work on same object as later is the Owner of the Incident. RF restricting the creator do only certain things on the Incident is achieved at the UI level. But in general, RF doesn’t really care about Incident creator. Whether a ServiceDesk Client creates an Incident for himself or ServiceDesk Staff creates an Incident on behalf some client, Incident sharing is governed exactly the same way. Even in the later case, access to incident object is granted to client (which is specified by client-id) and creator can’t even see that incident.

Sharing information in SFDC for objects with private and public read-only org-wide default is stored in an object whose API name ends with __Share. This object has kind-of ACL. For BMCServiceDesk__Incident__c object BMCServiceDesk__Incident__Share is where ACL is maintained.

Consider a couple of cases ( assume user A: Sally, user B: Yogesh, user C: Beena, A is ServiceDesk Client while B and C are ServiceDesk Staff).

User A creates an Incident (with id ‘00000067’) and it gets assigned to user B. If you run following SOQL

SELECT Id, CreatedBy.Name, Owner.Name, BMCServiceDesk__incidentDescription__c, BMCServiceDesk__clientId__c FROM BMCServiceDesk__Incident__c where Name = '00000067'

You will get Creator as A and Owner as B and client Id would be user-id of Sally. If you use Id obtained in above query and pass it as ParentId in query below

SELECT ParentId, UserOrGroupId, RowCause, AccessLevel FROM BMCServiceDesk__Incident__Share where ParentId = 'a1N900000025eMTEAY'

you will get following

a1N900000025eMTEAYUserId of SallyBMCServiceDesk__Incident_
a1N900000025eMTEAYUserId of YogeshOwnerAll

User C creates an Incident on behalf of user A and it gets assigned to user B. Even in this case, results of both the queries would be identical except Creator of the ticket which would be C in this case.

Above type of sharing is kind-of Manual Sharing achieved not declaratively but using Apex Managed Sharing. For Incident Object, if you take a look at ‘Apex Sharing Reasons’ related objects you will get 1 sharing reason with Label ‘Incident Clients Share for SS’ and Name ‘Incident_Clients_Share_for_SS’. RF assigns Sharing rights of ‘Edit’ to client id in Apex code. When you manually (or declaratively through SFDC UI) add to sharing of an object, RowCause appears as ‘Manual’.

This was a slight detour, hopefully with some insights. Let us get back to our original use-case of only HR people being able to see HR Incidents, IT people being able to see IT Incidents and so on. As we said earlier, on top of org-wide sharing model for an object, we can use “Role Hierarchies”, “Sharing Rules” and “Manual Sharing” to grant access to some records to some users. First and foremost, you need some field on Incident object which would help you identify type of Incident. Here I am assuming that field would be Category and for simplicity let us assume that it can 2 values HR and IT. By default, this field is not mandatory for Incident but you can do so by putting a validation rule.

Let us assume that HR incidents would get assigned to HR-Queue and IT Incidents to IT-Queue. Then it is just matter of assigning right support staff members to appropriate queue and you are done. You might want to prevent users higher up in hierarchy of HR and IT support staff from seeing the incidents. In that case, go to ‘Security Controls->Sharing Settings’, click on ‘Edit’ and uncheck ‘GRANT access using hierarchies’ for Incident object.

Make sure to have a role hierarchy where HR staff is under a node and IT staff under another node and these 2 nodes are non-overlapping. In this case, ‘GRANT access using hierarchies’ for Incident object has to be turned on. If you are running RF in an existing SFDC organization with role hierarchy already set, this approach may not be easy to implement.

The most flexible approach is by making use of Sharing rule. You can create a public group called ‘HR Group’, add appropriate to this group and set up sharing rule on Incident object with

  • Rule type as ‘Based on Criteria’
  • Criteria as ‘Category’ equals ‘HR’
  • Share with ‘HR Group’
  • Access level ‘Read/Write’

There is a catch here though, you can’t choose ‘Category’ in second step above as it is a lookup field and workaround for that is create a custom field to Incident object, auto-populate it with the value of ‘Category’ when Incident is created and use it in the criteria in second step above.

Yogesh Ketkar