Hi

Its noted in the documentation for Common Modules https://help.mypurecloud.com/articles/work-with-common-module-flows/ that they can "...share common actions and data types across different flow types...". 

Though I want to confirm that flow-specific but built-in data variables are never available in any Common Module regardless if they have been restricted to say only the Inbound Call flow?

For example, I have a Common Module that is only used for inbound call flow, but in the expressions in Architect, I don't have access to either of these variables:

- Call.Ani
- Call.ConversationId

The only built-in variables I can access are some System.* - variables like:

- Flow.version
- System.DateTime

My use case is I could simplify the flows that calls on my Common Module if I was able to use the built-in variables compatible with the called Common Module's flow type(s). 

For example, to look up a customer in our crm using a Common Module FindInCrm I could invoke the module from the calling flow like:

- FindInCrm(findByAni=true)

Instead of doing what I do now, which is to calculate some properties that I rather delegate as the Common Module's responsibilities:

- Task.ani = Replace(ToPhoneNumber(Call.Ani).e164, "+", "")
- FindInCrm(findByMsisdn=Task.ani, conversationId=Call.ConversationId)

Noted some logic in the example above could be moved into the Common Module, but I expected a variable like ConversationId might be available.

I mostly want confirmation that this "limitation/design decision" is real, and I haven't missed some setting that would enable this (the documentation of Common Module's are rather terse), since we will be doing a lot of refactoring of Architect Flows to use the new (and awesome) Common Modules, and this constraint is an important one to consider when we do so.
#SystemAdministration

------------------------------
Joel Hellman
Hi3G
------------------------------

The main concept of common modules is to act as an inline subroutine for the initial flow and allow input and output of data across multiple media types.  So create data attributes for input of the conversation or Ani for processing, do your lookup and then output the result.  The common module built-in attributes will depend on the media support defined in the module.

------------------------------
Robert Wakefield-Carl
Avtex Solutions, LLC
Contact Center Innovation Architect
robertwc@avtex.com
https://www.Avtex.com
https://RobertWC.Blogspot.com
------------------------------

Original Message:
Sent: 09-18-2021 01:44
From: Joel Hellman
Subject: Access to variables like Call.Ani and Call.ConversationId from Common Module

Hi

Its noted in the documentation for Common Modules https://help.mypurecloud.com/articles/work-with-common-module-flows/ that they can "...share common actions and data types across different flow types...".

Though I want to confirm that flow-specific but built-in data variables are never available in any Common Module regardless if they have been restricted to say only the Inbound Call flow?

For example, I have a Common Module that is only used for inbound call flow, but in the expressions in Architect, I don't have access to either of these variables:

- Call.Ani
- Call.ConversationId

The only built-in variables I can access are some System.* - variables like:

- Flow.version
- System.DateTime

My use case is I could simplify the flows that calls on my Common Module if I was able to use the built-in variables compatible with the called Common Module's flow type(s).

For example, to look up a customer in our crm using a Common Module FindInCrm I could invoke the module from the calling flow like:

- FindInCrm(findByAni=true)

Instead of doing what I do now, which is to calculate some properties that I rather delegate as the Common Module's responsibilities:

- Task.ani = Replace(ToPhoneNumber(Call.Ani).e164, "+", "")
- FindInCrm(findByMsisdn=Task.ani, conversationId=Call.ConversationId)

Noted some logic in the example above could be moved into the Common Module, but I expected a variable like ConversationId might be available.

I mostly want confirmation that this "limitation/design decision" is real, and I haven't missed some setting that would enable this (the documentation of Common Module's are rather terse), since we will be doing a lot of refactoring of Architect Flows to use the new (and awesome) Common Modules, and this constraint is an important one to consider when we do so.
#SystemAdministration

------------------------------
Joel Hellman
Hi3G
------------------------------

I like your reasoning how to think about the common modules as "inline subroutines". Then with the added caveat that built-in data variables typically accessible to the the calling Flow of the compatible are not available. 

> The common module built-in attributes will depend on the media support defined in the module.
Agreed, that's a bit vague though, it's as much as the documentation says on the topic, and I found in practice I expected and miss the availability of data variables. 

My takeway is that built-in data variables that are media-specific are not available in any common flows, while media-specific actions can be available, based on which flow types you have configured the common module to support.

To summarize with an example, a Common Module that supports the In-Queue and Inbound Call Flows, will:
1. let you use actions like Create Callback (compabitle with call flows), but not actions like Send reply (incompatible). 
2. let you access some generic data variables like System.DateTime or Flow.Version.
3. not let you access media specific data variables like Call.ConversationId (and ofc not Chat.ConversationId)

It would be nice to have support for bullet 3. above, but it's a nice-to-have.

But for any readers stumbling on this post, bullet 3 above is good to be aware of, as you might reason that data variables compatible with the support flows of a Common Module might be available to the Common Module, since actions are.

------------------------------
Joel Hellman
Hi3G
------------------------------

Original Message:
Sent: 09-18-2021 01:50
From: Robert Wakefield-Carl
Subject: Access to variables like Call.Ani and Call.ConversationId from Common Module

The main concept of common modules is to act as an inline subroutine for the initial flow and allow input and output of data across multiple media types.  So create data attributes for input of the conversation or Ani for processing, do your lookup and then output the result.  The common module built-in attributes will depend on the media support defined in the module.

------------------------------
Robert Wakefield-Carl
Avtex Solutions, LLC
Contact Center Innovation Architect
robertwc@avtex.com
https://www.Avtex.com
https://RobertWC.Blogspot.com

Original Message:
Sent: 09-18-2021 01:44
From: Joel Hellman
Subject: Access to variables like Call.Ani and Call.ConversationId from Common Module

Hi

Its noted in the documentation for Common Modules https://help.mypurecloud.com/articles/work-with-common-module-flows/ that they can "...share common actions and data types across different flow types...".

Though I want to confirm that flow-specific but built-in data variables are never available in any Common Module regardless if they have been restricted to say only the Inbound Call flow?

For example, I have a Common Module that is only used for inbound call flow, but in the expressions in Architect, I don't have access to either of these variables:

- Call.Ani
- Call.ConversationId

The only built-in variables I can access are some System.* - variables like:

- Flow.version
- System.DateTime

My use case is I could simplify the flows that calls on my Common Module if I was able to use the built-in variables compatible with the called Common Module's flow type(s).

For example, to look up a customer in our crm using a Common Module FindInCrm I could invoke the module from the calling flow like:

- FindInCrm(findByAni=true)

Instead of doing what I do now, which is to calculate some properties that I rather delegate as the Common Module's responsibilities:

- Task.ani = Replace(ToPhoneNumber(Call.Ani).e164, "+", "")
- FindInCrm(findByMsisdn=Task.ani, conversationId=Call.ConversationId)

Noted some logic in the example above could be moved into the Common Module, but I expected a variable like ConversationId might be available.

I mostly want confirmation that this "limitation/design decision" is real, and I haven't missed some setting that would enable this (the documentation of Common Module's are rather terse), since we will be doing a lot of refactoring of Architect Flows to use the new (and awesome) Common Modules, and this constraint is an important one to consider when we do so.
#SystemAdministration

------------------------------
Joel Hellman
Hi3G
------------------------------