Open APIs

 View Only
  • 1.  TMF 681 Communication API REST R18.0.0 - Preferred Multiple Channels

    Posted Sep 19, 2019 06:48
    Hi @Knut Johannessen,

    ​How do we cater to a business scenario where a customer has chosen preferred channels of communication for different types of notifications ? 

    This API expects a single input for type attribute in "CommunicationMessage". Can we use the same attribute to pass multiple channels, probably comma separated ? Or is the implementation expected to create 2 different notifications for two different channels ?

    @Hongxia Hao, see if you can also provide your views on this.


    ------------------------------
    Rabinder Devnani
    Sterlite Technologies Limited
    ------------------------------


  • 2.  RE: TMF 681 Communication API REST R18.0.0 - Preferred Multiple Channels

    TM Forum Member
    Posted Sep 20, 2019 02:41
    One of the points about the customer role that keeps getting lost is that "customer" is a role, not a person or "party".  As such, it is fluid, and depending on the nature of the relationship between the customer role and the selling organisation, variable.

    So we should expect that a person may choose to be many customers, or the same customer, when interacting with an organisation.  This becomes legally significant when operating in a country with strong privacy laws, where a party may choose that particular channels apply to a particular customer role, and using those channels for a different customer role may expose the selling organisation to litigation.  An example use case of this nature is a long standing customer selecting eMail as the only communication channel, but then requesting the voice channel for interacting around a newly launched promotion.  Pity the organisation that decides this is a moment for cold calling about the prior existing products. 

    The point is that the "customer" role is not universal, but is bound by the implied or real agreement between the "party" and the selling organisation.

    ------------------------------
    Hugo Vaughan
    Crowd Frame Consulting Limited.
    ------------------------------



  • 3.  RE: TMF 681 Communication API REST R18.0.0 - Preferred Multiple Channels

    Posted Oct 15, 2019 02:33
    Edited by Rabinder Devnani Oct 15, 2019 02:37
    Thanks @Hugo Vaughan for your reply.

    My question was more from the API technicality perspective. Currently the API supports a single attribute which allows source system to select which type of notification it wants to send. Now my concern is that if there is a requirements saying that "Payment Receipt" should be sent via e-mail & SMS both ​then can we use the same attribute to pass multiple types (e.g. comma separated) given that the content is being managed by system implementing "Communications API" ? Because here it is expected to send the content according to the notification type and hence if we pass, we will need to pass multiple content also linking it with type which will change the complete structure of the API in my view.

    ------------------------------
    Rabinder Devnani
    Sterlite Technologies Limited
    ------------------------------



  • 4.  RE: TMF 681 Communication API REST R18.0.0 - Preferred Multiple Channels

    TM Forum Member
    Posted Oct 15, 2019 05:37
    Good point.

    Perhaps what you are looking at is the current base pattern in the SID of Atomic/Composite.  In your use case Atomic/Array/Composite would be a useful pattern.

    Any comments for the SID group?  I can see this pattern of use case can exist for virtually any class as we see greater emphisis on 360 views of the subject.

    ------------------------------
    Hugo Vaughan
    Crowd Frame Consulting Limited.
    ------------------------------