You are hereHome Customizations
  • This is a bit of a variation on a theme I did a while ago when I talked about using filtered views for address population. In this case I wanted to explore if we could set up a subject-like hierarchy and then use filtered lookups to enter category levels easily against an account. It turns out it works quite nicely. image

    Essentially, you set the first category from you list of top level categories. Then, you set level 2 which will automatically adjust to only the valid values, based on the category 1 value. Finally, you set the category 3 value, based on the value in category 2.

    So How Do I Set This Up?

    First of all, we create a new Category entity. image In this case I have stripped everything out; there are no notes, activities etc. and the record is organization owned. Next I set up a recursive 1:N relationship so that for a given category I can set an infinite number of category levels, each with an infinite number of categories. image The main points of interest here are the changing of the display name to ‘Parent Category’ and the changing of the display option to ‘Use Custom Label’ so I can refer to the next level down as ‘Sub Categories’. On the category form I also add the parent category lookup, created as a result of this relationship. image Finally, I add three lookups to the account form so I can add three levels of category to my account record. image Finally, I populate my category hierarchy. Unfortunately, there is no nice tree view to employ so I fill it up in pretty much the same way I would if I was populating, for example, an account hierarchy. My advice would be to do it via a data import.

    Where’s The Magic?

    So far this will just let us pick three category values from all category values and add them to an account; not exactly exciting. The trick comes in adjusting the filters on the lookups. For category 1, we set up a new system view called Level 1 Categories. This just shows those categories with no parent category i.e. they are at the top of the tree. image We then go to our first lookup and force it to only use this view for its values. image The result is when we click the lookup only the values in the top level appear. image For the other two lookups, we use the Related Records Filtering properties of the lookup. For the category 2 lookup, we set it as follows: image The setup for the category 3 lookup is identical, except we replace ‘Category 1 (Accounts)’ with ‘Category 2 (Accounts)’. This means, clicking on, say, the category 2 lookup shows only the valid values, based on the selection for category 1. image And that is it. With all that set up, all the user has to do is pick the category 1 value and the category 2 values will be auto-filtered. Once the category 2 value is selected, the category 3 values will filter.

    Why Not Use Subjects?

    Subjects are nice in that they can be linked to an account with a 1:N relationship and they have a tree view lookup. However, they do not, at this time, play nicely with lookup filters. If you add a subject lookup to an account form and try to filter its values, based on the selection in another subject lookup, CRM throws an error. This has been reported and, I am sure, will be addressed in a future roll-up.

    Conclusions

    If you have a multi-level hierarchy you wish to apply to a record, such as an account, and you are looking for a reasonably user-friendly way to capture the information this is not such a bad solution and does not require code or Silverlight web resources. While my first choice would be the subject entity, because of its friendly tree view, if this is not practical, this solution provides an alternative approach which supports any number of category levels.
">
  • This is a bit of a variation on a theme I did a while ago when I talked about using filtered views for address population. In this case I wanted to explore if we could set up a subject-like hierarchy and then use filtered lookups to enter category levels easily against an account. It turns out it works quite nicely. image

    Essentially, you set the first category from you list of top level categories. Then, you set level 2 which will automatically adjust to only the valid values, based on the category 1 value. Finally, you set the category 3 value, based on the value in category 2.

    So How Do I Set This Up?

    First of all, we create a new Category entity. image In this case I have stripped everything out; there are no notes, activities etc. and the record is organization owned. Next I set up a recursive 1:N relationship so that for a given category I can set an infinite number of category levels, each with an infinite number of categories. image The main points of interest here are the changing of the display name to ‘Parent Category’ and the changing of the display option to ‘Use Custom Label’ so I can refer to the next level down as ‘Sub Categories’. On the category form I also add the parent category lookup, created as a result of this relationship. image Finally, I add three lookups to the account form so I can add three levels of category to my account record. image Finally, I populate my category hierarchy. Unfortunately, there is no nice tree view to employ so I fill it up in pretty much the same way I would if I was populating, for example, an account hierarchy. My advice would be to do it via a data import.

    Where’s The Magic?

    So far this will just let us pick three category values from all category values and add them to an account; not exactly exciting. The trick comes in adjusting the filters on the lookups. For category 1, we set up a new system view called Level 1 Categories. This just shows those categories with no parent category i.e. they are at the top of the tree. image We then go to our first lookup and force it to only use this view for its values. image The result is when we click the lookup only the values in the top level appear. image For the other two lookups, we use the Related Records Filtering properties of the lookup. For the category 2 lookup, we set it as follows: image The setup for the category 3 lookup is identical, except we replace ‘Category 1 (Accounts)’ with ‘Category 2 (Accounts)’. This means, clicking on, say, the category 2 lookup shows only the valid values, based on the selection for category 1. image And that is it. With all that set up, all the user has to do is pick the category 1 value and the category 2 values will be auto-filtered. Once the category 2 value is selected, the category 3 values will filter.

    Why Not Use Subjects?

    Subjects are nice in that they can be linked to an account with a 1:N relationship and they have a tree view lookup. However, they do not, at this time, play nicely with lookup filters. If you add a subject lookup to an account form and try to filter its values, based on the selection in another subject lookup, CRM throws an error. This has been reported and, I am sure, will be addressed in a future roll-up.

    Conclusions

    If you have a multi-level hierarchy you wish to apply to a record, such as an account, and you are looking for a reasonably user-friendly way to capture the information this is not such a bad solution and does not require code or Silverlight web resources. While my first choice would be the subject entity, because of its friendly tree view, if this is not practical, this solution provides an alternative approach which supports any number of category levels.
    • ">
  • This is a bit of a variation on a theme I did a while ago when I talked about using filtered views for address population. In this case I wanted to explore if we could set up a subject-like hierarchy and then use filtered lookups to enter category levels easily against an account. It turns out it works quite nicely. image

    Essentially, you set the first category from you list of top level categories. Then, you set level 2 which will automatically adjust to only the valid values, based on the category 1 value. Finally, you set the category 3 value, based on the value in category 2.

    So How Do I Set This Up?

    First of all, we create a new Category entity. image In this case I have stripped everything out; there are no notes, activities etc. and the record is organization owned. Next I set up a recursive 1:N relationship so that for a given category I can set an infinite number of category levels, each with an infinite number of categories. image The main points of interest here are the changing of the display name to ‘Parent Category’ and the changing of the display option to ‘Use Custom Label’ so I can refer to the next level down as ‘Sub Categories’. On the category form I also add the parent category lookup, created as a result of this relationship. image Finally, I add three lookups to the account form so I can add three levels of category to my account record. image Finally, I populate my category hierarchy. Unfortunately, there is no nice tree view to employ so I fill it up in pretty much the same way I would if I was populating, for example, an account hierarchy. My advice would be to do it via a data import.

    Where’s The Magic?

    So far this will just let us pick three category values from all category values and add them to an account; not exactly exciting. The trick comes in adjusting the filters on the lookups. For category 1, we set up a new system view called Level 1 Categories. This just shows those categories with no parent category i.e. they are at the top of the tree. image We then go to our first lookup and force it to only use this view for its values. image The result is when we click the lookup only the values in the top level appear. image For the other two lookups, we use the Related Records Filtering properties of the lookup. For the category 2 lookup, we set it as follows: image The setup for the category 3 lookup is identical, except we replace ‘Category 1 (Accounts)’ with ‘Category 2 (Accounts)’. This means, clicking on, say, the category 2 lookup shows only the valid values, based on the selection for category 1. image And that is it. With all that set up, all the user has to do is pick the category 1 value and the category 2 values will be auto-filtered. Once the category 2 value is selected, the category 3 values will filter.

    Why Not Use Subjects?

    Subjects are nice in that they can be linked to an account with a 1:N relationship and they have a tree view lookup. However, they do not, at this time, play nicely with lookup filters. If you add a subject lookup to an account form and try to filter its values, based on the selection in another subject lookup, CRM throws an error. This has been reported and, I am sure, will be addressed in a future roll-up.

    Conclusions

    If you have a multi-level hierarchy you wish to apply to a record, such as an account, and you are looking for a reasonably user-friendly way to capture the information this is not such a bad solution and does not require code or Silverlight web resources. While my first choice would be the subject entity, because of its friendly tree view, if this is not practical, this solution provides an alternative approach which supports any number of category levels.
    • ">
  • This is a bit of a variation on a theme I did a while ago when I talked about using filtered views for address population. In this case I wanted to explore if we could set up a subject-like hierarchy and then use filtered lookups to enter category levels easily against an account. It turns out it works quite nicely. image

    Essentially, you set the first category from you list of top level categories. Then, you set level 2 which will automatically adjust to only the valid values, based on the category 1 value. Finally, you set the category 3 value, based on the value in category 2.

    So How Do I Set This Up?

    First of all, we create a new Category entity. image In this case I have stripped everything out; there are no notes, activities etc. and the record is organization owned. Next I set up a recursive 1:N relationship so that for a given category I can set an infinite number of category levels, each with an infinite number of categories. image The main points of interest here are the changing of the display name to ‘Parent Category’ and the changing of the display option to ‘Use Custom Label’ so I can refer to the next level down as ‘Sub Categories’. On the category form I also add the parent category lookup, created as a result of this relationship. image Finally, I add three lookups to the account form so I can add three levels of category to my account record. image Finally, I populate my category hierarchy. Unfortunately, there is no nice tree view to employ so I fill it up in pretty much the same way I would if I was populating, for example, an account hierarchy. My advice would be to do it via a data import.

    Where’s The Magic?

    So far this will just let us pick three category values from all category values and add them to an account; not exactly exciting. The trick comes in adjusting the filters on the lookups. For category 1, we set up a new system view called Level 1 Categories. This just shows those categories with no parent category i.e. they are at the top of the tree. image We then go to our first lookup and force it to only use this view for its values. image The result is when we click the lookup only the values in the top level appear. image For the other two lookups, we use the Related Records Filtering properties of the lookup. For the category 2 lookup, we set it as follows: image The setup for the category 3 lookup is identical, except we replace ‘Category 1 (Accounts)’ with ‘Category 2 (Accounts)’. This means, clicking on, say, the category 2 lookup shows only the valid values, based on the selection for category 1. image And that is it. With all that set up, all the user has to do is pick the category 1 value and the category 2 values will be auto-filtered. Once the category 2 value is selected, the category 3 values will filter.

    Why Not Use Subjects?

    Subjects are nice in that they can be linked to an account with a 1:N relationship and they have a tree view lookup. However, they do not, at this time, play nicely with lookup filters. If you add a subject lookup to an account form and try to filter its values, based on the selection in another subject lookup, CRM throws an error. This has been reported and, I am sure, will be addressed in a future roll-up.

    Conclusions

    If you have a multi-level hierarchy you wish to apply to a record, such as an account, and you are looking for a reasonably user-friendly way to capture the information this is not such a bad solution and does not require code or Silverlight web resources. While my first choice would be the subject entity, because of its friendly tree view, if this is not practical, this solution provides an alternative approach which supports any number of category levels.
    • ">
  • This is a bit of a variation on a theme I did a while ago when I talked about using filtered views for address population. In this case I wanted to explore if we could set up a subject-like hierarchy and then use filtered lookups to enter category levels easily against an account. It turns out it works quite nicely. image

    Essentially, you set the first category from you list of top level categories. Then, you set level 2 which will automatically adjust to only the valid values, based on the category 1 value. Finally, you set the category 3 value, based on the value in category 2.

    So How Do I Set This Up?

    First of all, we create a new Category entity. image In this case I have stripped everything out; there are no notes, activities etc. and the record is organization owned. Next I set up a recursive 1:N relationship so that for a given category I can set an infinite number of category levels, each with an infinite number of categories. image The main points of interest here are the changing of the display name to ‘Parent Category’ and the changing of the display option to ‘Use Custom Label’ so I can refer to the next level down as ‘Sub Categories’. On the category form I also add the parent category lookup, created as a result of this relationship. image Finally, I add three lookups to the account form so I can add three levels of category to my account record. image Finally, I populate my category hierarchy. Unfortunately, there is no nice tree view to employ so I fill it up in pretty much the same way I would if I was populating, for example, an account hierarchy. My advice would be to do it via a data import.

    Where’s The Magic?

    So far this will just let us pick three category values from all category values and add them to an account; not exactly exciting. The trick comes in adjusting the filters on the lookups. For category 1, we set up a new system view called Level 1 Categories. This just shows those categories with no parent category i.e. they are at the top of the tree. image We then go to our first lookup and force it to only use this view for its values. image The result is when we click the lookup only the values in the top level appear. image For the other two lookups, we use the Related Records Filtering properties of the lookup. For the category 2 lookup, we set it as follows: image The setup for the category 3 lookup is identical, except we replace ‘Category 1 (Accounts)’ with ‘Category 2 (Accounts)’. This means, clicking on, say, the category 2 lookup shows only the valid values, based on the selection for category 1. image And that is it. With all that set up, all the user has to do is pick the category 1 value and the category 2 values will be auto-filtered. Once the category 2 value is selected, the category 3 values will filter.

    Why Not Use Subjects?

    Subjects are nice in that they can be linked to an account with a 1:N relationship and they have a tree view lookup. However, they do not, at this time, play nicely with lookup filters. If you add a subject lookup to an account form and try to filter its values, based on the selection in another subject lookup, CRM throws an error. This has been reported and, I am sure, will be addressed in a future roll-up.

    Conclusions

    If you have a multi-level hierarchy you wish to apply to a record, such as an account, and you are looking for a reasonably user-friendly way to capture the information this is not such a bad solution and does not require code or Silverlight web resources. While my first choice would be the subject entity, because of its friendly tree view, if this is not practical, this solution provides an alternative approach which supports any number of category levels. ">

    • Category Archives: Customizations

    Dynamics CRM 2011- Setting Multi-Level Categories Against a Record Codelessly

    Nice Summary from Leon:

    This is a bit of a variation on a theme I did a while ago when I talked about using filtered views for address population. In this case I wanted to explore if we could set up a subject-like hierarchy and then use filtered lookups to enter category levels easily against an account. It turns out it works quite nicely. image

    Essentially, you set the first category from you list of top level categories. Then, you set level 2 which will automatically adjust to only the valid values, based on the category 1 value. Finally, you set the category 3 value, based on the value in category 2.

    So How Do I Set This Up?

    First of all, we create a new Category entity. image In this case I have stripped everything out; there are no notes, activities etc. and the record is organization owned. Next I set up a recursive 1:N relationship so that for a given category I can set an infinite number of category levels, each with an infinite number of categories. image The main points of interest here are the changing of the display name to ‘Parent Category’ and the changing of the display option to ‘Use Custom Label’ so I can refer to the next level down as ‘Sub Categories’. On the category form I also add the parent category lookup, created as a result of this relationship. image Finally, I add three lookups to the account form so I can add three levels of category to my account record. image Finally, I populate my category hierarchy. Unfortunately, there is no nice tree view to employ so I fill it up in pretty much the same way I would if I was populating, for example, an account hierarchy. My advice would be to do it via a data import.

    Where’s The Magic?

    So far this will just let us pick three category values from all category values and add them to an account; not exactly exciting. The trick comes in adjusting the filters on the lookups. For category 1, we set up a new system view called Level 1 Categories. This just shows those categories with no parent category i.e. they are at the top of the tree. image We then go to our first lookup and force it to only use this view for its values. image The result is when we click the lookup only the values in the top level appear. image For the other two lookups, we use the Related Records Filtering properties of the lookup. For the category 2 lookup, we set it as follows: image The setup for the category 3 lookup is identical, except we replace ‘Category 1 (Accounts)’ with ‘Category 2 (Accounts)’. This means, clicking on, say, the category 2 lookup shows only the valid values, based on the selection for category 1. image And that is it. With all that set up, all the user has to do is pick the category 1 value and the category 2 values will be auto-filtered. Once the category 2 value is selected, the category 3 values will filter.

    Why Not Use Subjects?

    Subjects are nice in that they can be linked to an account with a 1:N relationship and they have a tree view lookup. However, they do not, at this time, play nicely with lookup filters. If you add a subject lookup to an account form and try to filter its values, based on the selection in another subject lookup, CRM throws an error. This has been reported and, I am sure, will be addressed in a future roll-up.

    Conclusions

    If you have a multi-level hierarchy you wish to apply to a record, such as an account, and you are looking for a reasonably user-friendly way to capture the information this is not such a bad solution and does not require code or Silverlight web resources. While my first choice would be the subject entity, because of its friendly tree view, if this is not practical, this solution provides an alternative approach which supports any number of category levels.

    Posted in Customizations
    by
    Monday, 24 September 2012
    with 0 comment

    Nice Summary from Leon:

    This is a bit of a variation on a theme I did a while ago when I talked about using filtered views for address population. In this case I wanted to explore if we could set up a subject-like hierarchy and then use filtered lookups to enter category levels easily against an account. It turns out it works quite nicely.

    image

    Essentially, you set the first category from you list of top level categories. Then, you set level 2 which will automatically adjust to only the valid values, based on the category 1 value. Finally, you set the category 3 value, based on the value in category 2.

    So How Do I Set This Up?

    First of all, we create a new Category entity.

    image

    In this case I have stripped everything out; there are no notes, activities etc. and the record is organization owned.

    Next I set up a recursive 1:N relationship so that for a given category I can set an infinite number of category levels, each with an infinite number of categories.

    image

    The main points of interest here are the changing of the display name to ‘Parent Category’ and the changing of the display option to ‘Use Custom Label’ so I can refer to the next level down as ‘Sub Categories’.

    On the category form I also add the parent category lookup, created as a result of this relationship.

    image

    Finally, I add three lookups to the account form so I can add three levels of category to my account record.

    image

    Finally, I populate my category hierarchy. Unfortunately, there is no nice tree view to employ so I fill it up in pretty much the same way I would if I was populating, for example, an account hierarchy. My advice would be to do it via a data import.

    Where’s The Magic?

    So far this will just let us pick three category values from all category values and add them to an account; not exactly exciting.

    The trick comes in adjusting the filters on the lookups.

    For category 1, we set up a new system view called Level 1 Categories. This just shows those categories with no parent category i.e. they are at the top of the tree.

    image

    We then go to our first lookup and force it to only use this view for its values.

    image

    The result is when we click the lookup only the values in the top level appear.

    image

    For the other two lookups, we use the Related Records Filtering properties of the lookup. For the category 2 lookup, we set it as follows:

    image

    The setup for the category 3 lookup is identical, except we replace ‘Category 1 (Accounts)’ with ‘Category 2 (Accounts)’.

    This means, clicking on, say, the category 2 lookup shows only the valid values, based on the selection for category 1.

    image

    And that is it. With all that set up, all the user has to do is pick the category 1 value and the category 2 values will be auto-filtered. Once the category 2 value is selected, the category 3 values will filter.

    Why Not Use Subjects?

    Subjects are nice in that they can be linked to an account with a 1:N relationship and they have a tree view lookup. However, they do not, at this time, play nicely with lookup filters. If you add a subject lookup to an account form and try to filter its values, based on the selection in another subject lookup, CRM throws an error. This has been reported and, I am sure, will be addressed in a future roll-up.

    Conclusions

    If you have a multi-level hierarchy you wish to apply to a record, such as an account, and you are looking for a reasonably user-friendly way to capture the information this is not such a bad solution and does not require code or Silverlight web resources. While my first choice would be the subject entity, because of its friendly tree view, if this is not practical, this solution provides an alternative approach which supports any number of category levels.

    Read More

    Microsoft Dynamics CRM 2011: How to launch a Dialog on click of custom ribbon button?

    Posted in Customizations
    by
    Monday, 24 September 2012
    with 0 comment

    Microsoft Dynamics CRM 2011: How to launch a Dialog on click of custom ribbon button?

    In this post I will explain how to launch a Dialog from Ribbon Button in Dynamics CRM. The requirement is like configure a custom ribbon button on custom entity which will launch a dialog (Process).

    In this Example, I’ve used custom entity “Flight Route” contains a button called “Test Button” which will launch a dialog. Dialog will select a flight name from the option set and insert new note record on the selected flight route record.

    Following are steps that demonstrate launch dialog from ribbon button.

    Before to start with a launch dialog, we need to create
    1. Create a dialog for “Flight Route” entity
    · Select Solution.
    · Select Processes.
    · Create new process.

    clip_image002

    · Specify the Process name.
    · Select Entity.
    · Select “Activate as” as “Process” and “Category” as “Dialog”.
    · Configure it as an on-demand process.
    · For this dialog make sure that it should contain at least one
    “Prompt and Response”

    clip_image004

    2. Javascript Library as a web resource
    · Create new Web resource” /javascripts/LaunchModalDialog.js”

    clip_image006

    · Click on Text Editor.
    Insert below function in Text editor window.

       1: function LaunchModalDialog(dialogId,typeName,recordId)
       2: {
       3: var serverUrl = Xrm.Page.context.getServerUrl();
       4: recordId=recordId.replace("{", "");
       5: recordId=recordId.replace("}", "");
       6:
       7: dialogId=dialogId.replace("{", "");
       8: dialogId=dialogId.replace("}", "");
       9:
      10: // Load modal
      11: var serverUri = serverUrl +'/cs/dialog/rundialog.aspx';
      12:
      13: var mypath =  serverUri +'?DialogId=%7b' +dialogId.toUpperCase()  +'%7d&EntityName=' + typeName+'&ObjectId=%7b' +recordId+'%7d';
      14:
      15: // First item from selected contacts only
      16: window.showModalDialog(mypath);
      17:
      18: // Reload form.
      19: window.location.reload(true);
      20: }

    In above JavaScript method I have used 3 different parameters.

    dialogId is id of the dialog we need to open from button (String Parameter)
    typeName is entity’s logical name (String Parameter)
    recordId is entity’s current record id form where the dialog will be launched.

    3. Get the Dialog Id Value
    · Once you have created new dialog.
    · Click Start Dialog.

    clip_image002[4]

    · That will open new dialog window.
    · Get the dialog id value from the URL(Ctrl+N) and note it down somewhere,
    to use the same in coming steps.

    clip_image003

    4. Insert custom button on entity’s form using Visual Ribbon editor. ( To create a new button on ribbon, you can refer below link—)

    http://ankit.inkeysolutions.com/2012/01/crm-2011-how-to-use-visual-ribbon.html

    5. After inserting a new custom button,
    follow the below steps to add JavaScript function with parameters
    · Click on Add link for specifying the “Function name” and “Library”
    a. Specify function name and library name.
    b. Click on “Add” link as shown below. It will open a list of
    parameter types which you can pass with the function.

    clip_image001

    As discussed earlier (refer step 2) we need 3 different parameters to call JavaScript method. Pass those values as described below. The first parameter will be the value which we have noted in step 3. The second one is entity name. And the last one is the record GUID.

    clip_image002[6]

    · Clicks on save. It will save and publish the changes on CRM server.

    clip_image003[4]

    6. Now you can verify the button on your entity’s form ribbon.

    clip_image005

    7. On click of this button your dialog will be launched.

    clip_image007

    8. Select Flight Name from the list and click next and then Finish on the last screen.

    clip_image009

    9. At the end, a note will be generated on Flight Route entity

    clip_image011

    Read More

    Microsoft Dynamics CRM 2011: How to use Visual Ribbon Editor Tool?

    Posted in Customizations
    by
    Monday, 24 September 2012
    with 0 comment

    Microsoft Dynamics CRM 2011: How to use Visual Ribbon Editor Tool?

    Recently, I was assigned a task of ribbon customization in Dynamics CRM. The requirement was like configure a custom ribbon button on custom entity to call some JavaScript methods. I’ve used the Visual Ribbon Editor Tool. This tool is quite handy and intuitive for ribbon customization. I would like to share my experience here in below post.

    Before to start with a Ribbon Editor Tool, let’s first configure the web resources (Images and JavaScript file).

    The images will be used as an icon on a button. Below are 3 different types that CRM supports. Image formats can be PNG, JPG, GIF or ICO.

    1. Small: 16 x 16 pixels
    2. Medium: 32 x 32 pixels
    3. Large: 66 x 48 pixels

    Following are the steps to add image to web resource
    1. Click Web Resources on left navigation pane in your solution.

    image

    2. Click New to add web resource record.
    3. Specify the name and the display name.
    4. Select Format of the image.
    5. Click browse to select an image path to upload image.
    6. Save and publish the newly created web resource record.

    image

    Follow the same process to add 32×32 Image.

    Let’s add a JavaScript function which will be called on custom button click
    These are the steps to add new Library as web resource

    1. Repeat steps 1-3 as above
    2. Select Script(JScript) as Type of web resource.

    image

    3. Click on Text Editor.
    4. Insert below function in Text editor window

       1: function TestRibbon()
       2: {
       3:    alert("Test Ribbon Customization using Visual Ribbon Editor.");
       4: }

    image

    5. Click ok.
    6. Save and publish a web resource

    Now it’s time to play with Visual Ribbon Editor Tool. Use below link to download it. http://crmvisualribbonedit.codeplex.com/releases/view/75530

    Extract the files and Run “VisualRibbonEditor.exe”

    image

    1. Click imageon top – left of the screen named as “Connection Info..” ,

    image

    2. Specify the connection details

    image

    3. Once connected, click on image button.

    image

    4. Select the required entity for ribbon customization.

    image

    5. By default, It Loads the ribbon type as Form

    image

    6. If you want to create a new Group then click on “New Group” button.

    image

    7. Specify the ID
    image

    Instead of creating new group, you could also add the button on existing group.For that you just need to select any existing group.

    image

    In this example I have created a new group. It will be added at the last position on ribbon toolbar.
    image

    8. Click on New Button to insert a button on above group.

    image

    9. Specify the button name.

    image

    10. Specify the following details for the newly created button on Details tab.

    a. Id: Defines button id.
    b. Label: Defines caption or display text for button.
    c. Tooltip: Defines tooltip text for the button.
    d. Template Alias: Defines how button will be displayed on ribbon with Large, medium, small icon and it also vary depending on the selected Template of group.(step-7)

      • 01(Large) : Defines large image (32×32).
      • 02(Medium): Defines small image (16×16).
      • isv(Medium): Defines small image (16×16).

    image

    e. Sequence: Use arrow buttons to setup a sequence of custom button.
    f. 16×16 Image: Name of button image from web resource (16×16).(Created as a web resource earlier)
    g. 32×32 Image: Name of button image from web resource (32×32). (Created as a web resource earlier)

    image

    11. Now, click on Action tab shown as below.
    12. Click on Add link for specifying the “Function name” and “Library”

    image

    You can also use “Display Rules” and “Enable Rules” via this tool which will allow us to configure many criteria for enabling/disabling a custom button.

    13. Click on Save button that will import the solution in CRM

    image

    image

    14. Now you can verify the button on your entity’s form ribbon.

    image

    15. On click of this button you’ll get the JavaScript alert Message.

    image

    Read More

    Calculate the Actual Value of an Opportunity in Microsoft Dynamics CRM 2011 Using .NET or Jscript

    Posted in Customizations
    by
    Monday, 24 September 2012
    with 0 comment

    Calculate the Actual Value of an Opportunity in Microsoft Dynamics CRM 2011 Using .NET or Jscript

    This illustration shows how to calculate the actual value of an opportunity in Microsoft Dynamics CRM 2011 with CalculateActualValueOpportunityRequest. This example will be given in Jscript (SOAP) and in C# (.NET).

    Ok, here is what the code looks like!

    First in C#:
     CalculateActualValueOpportunityRequest req = new CalculateActualValueOpportunityRequest(); req.OpportunityId = new Guid("F66A58B1-6847-E111-8D3C-1CC1DEF1353B"); CalculateActualValueOpportunityResponse resp = (CalculateActualValueOpportunityResponse)service.Execute(req);

    If you need help instantiating a service object in .NET within a plugin check out this post: http://mileyja.blogspot.com/2011/04/instantiating-service-object-within.html

    Now here is the Jscript nicely formatted by the CRM 2011 SOAP formatter. Available at: http://crm2011soap.codeplex.com/
    Now in Jscript
    This example is asynchronous, if you want to learn how to make JScript SOAP calls synchronously please visit this post: http://mileyja.blogspot.com/2011/07/using-jscript-to-access-soap-web.html
     if (typeof (SDK) == "undefined") { SDK = { __namespace: true }; } //This will establish a more unique namespace for functions in this library. This will reduce the // potential for functions to be overwritten due to a duplicate name when the library is loaded. SDK.SAMPLES = { _getServerUrl: function () { ///<summary> /// Returns the URL for the SOAP endpoint using the context information available in the form /// or HTML Web resource. ///</summary> var ServicePath = "/XRMServices/2011/Organization.svc/web"; var serverUrl = ""; if (typeof GetGlobalContext == "function") { var context = GetGlobalContext(); serverUrl = context.getServerUrl(); } else { if (typeof Xrm.Page.context == "object") { serverUrl = Xrm.Page.context.getServerUrl(); } else { throw new Error("Unable to access the server URL"); } } if (serverUrl.match(/\/$/)) { serverUrl = serverUrl.substring(0, serverUrl.length - 1); } return serverUrl + ServicePath; }, CalculateActualValueOpportunityRequest: function () { var requestMain = "" requestMain += "<s:Envelope xmlns:s=\"http://schemas.xmlsoap.org/soap/envelope/\">"; requestMain += " <s:Body>"; requestMain += " <Execute xmlns=\"http://schemas.microsoft.com/xrm/2011/Contracts/Services\" xmlns:i=\"http://www.w3.org/2001/XMLSchema-instance\">"; requestMain += " <request i:type=\"b:CalculateActualValueOpportunityRequest\" xmlns:a=\"http://schemas.microsoft.com/xrm/2011/Contracts\" xmlns:b=\"http://schemas.microsoft.com/crm/2011/Contracts\">"; requestMain += " <a:Parameters xmlns:c=\"http://schemas.datacontract.org/2004/07/System.Collections.Generic\">"; requestMain += " <a:KeyValuePairOfstringanyType>"; requestMain += " <c:key>OpportunityId</c:key>"; requestMain += " <c:value i:type=\"d:guid\" xmlns:d=\"http://schemas.microsoft.com/2003/10/Serialization/\">f66a58b1-6847-e111-8d3c-1cc1def1353b</c:value>"; requestMain += " </a:KeyValuePairOfstringanyType>"; requestMain += " </a:Parameters>"; requestMain += " <a:RequestId i:nil=\"true\" />"; requestMain += " <a:RequestName>CalculateActualValueOpportunity</a:RequestName>"; requestMain += " </request>"; requestMain += " </Execute>"; requestMain += " </s:Body>"; requestMain += "</s:Envelope>"; var req = new XMLHttpRequest(); req.open("POST", SDK.SAMPLES._getServerUrl(), true) req.setRequestHeader("Accept", "application/xml, text/xml, */*"); req.setRequestHeader("Content-Type", "text/xml; charset=utf-8"); req.setRequestHeader("SOAPAction", "http://schemas.microsoft.com/xrm/2011/Contracts/Services/IOrganizationService/Execute"); var successCallback = null; var errorCallback = null; req.onreadystatechange = function () { SDK.SAMPLES.CalculateActualValueOpportunityResponse(req, successCallback, errorCallback); }; req.send(requestMain); }, CalculateActualValueOpportunityResponse: function (req, successCallback, errorCallback) { ///<summary> /// Recieves the assign response ///</summary> ///<param name="req" Type="XMLHttpRequest"> /// The XMLHttpRequest response ///</param> ///<param name="successCallback" Type="Function"> /// The function to perform when an successfult response is returned. /// For this message no data is returned so a success callback is not really necessary. ///</param> ///<param name="errorCallback" Type="Function"> /// The function to perform when an error is returned. /// This function accepts a JScript error returned by the _getError function ///</param> if (req.readyState == 4) { if (req.status == 200) { if (successCallback != null) { successCallback(); } } else { errorCallback(SDK.SAMPLES._getError(req.responseXML)); } } }, _getError: function (faultXml) { ///<summary> /// Parses the WCF fault returned in the event of an error. ///</summary> ///<param name="faultXml" Type="XML"> /// The responseXML property of the XMLHttpRequest response. ///</param> var errorMessage = "Unknown Error (Unable to parse the fault)"; if (typeof faultXml == "object") { try { var bodyNode = faultXml.firstChild.firstChild; //Retrieve the fault node for (var i = 0; i < bodyNode.childNodes.length; i++) { var node = bodyNode.childNodes[i]; //NOTE: This comparison does not handle the case where the XML namespace changes if ("s:Fault" == node.nodeName) { for (var j = 0; j < node.childNodes.length; j++) { var faultStringNode = node.childNodes[j]; if ("faultstring" == faultStringNode.nodeName) { errorMessage = faultStringNode.text; break; } } break; } } } catch (e) { }; } return new Error(errorMessage); }, __namespace: true };
    To understand how to parse the response please review my post on using the DOM parser.
    Now you can call the SDK.SAMPLES.CalculateActualValueOpportunityRequest function from your form jscript handler.
    Thats all there is to it!
    Read More

    Quick Contacts

    Fragen? Quick Contact +49 89 414 375 00 info@dynamicsconsulting.de

    Ihr Name (required)

    Ihre Email (required)

    Betreff

    Ihre Nachicht

    Quick Contacts

    Fragen? Quick Contact +49 89 414 375 00 info@dynamicsconsulting.de

    Ihr Name (required)

    Ihre Email (required)

    Betreff

    Ihre Nachicht

    PDF Downloads

      Dynamics_CRM_2011_Überblick.pdf
      Dynamics_CRM_2011_Vertrieb.pdf
      Dynamics_CRM_2011_Marketing.pdf
      Dynamics_CRM_2011_Service.pdf
      Dynamics CRM Mobiles Arbeiten.pdf